2

MongoDB/Morphia を使用する古い Java コードベースを段階的に廃止しようとしています。この移行中、新しいプラットフォームが同じ MongoDB データベース/コレクションに書き込み、それぞれがしばらくの間共存できるようにしたいと考えています。その部分は大丈夫です。私の問題は、新しいプラットフォームでは、現在コレクションにあるものとは異なる、morphia でマッピングしているオブジェクトのパッケージ/クラス構造が必要なことです。

たとえば、古いプラットフォームでは、次のクラスがあります。

package com.foo;

@Entity
public class Bar {
    @Id private String id;
    private String name;
    ...
}

私のmongoデータベースには、コレクション「Bar」があり、そのドキュメントには「com.foo.Bar」に設定されたclassName属性があります。それはすべて素晴らしいです。

私が新しいプラットフォームでやりたいことは、そのエンティティを表す別のパッケージにまったく新しいクラスを作成することですが、同じ方法で mongo と対話させます。私はこのようなことができることを望んでいます:

package com.foo.legacy;

@Entity("com.foo.Bar")
public class LegacyBar {
    @Id private String id;
    private String name;
    ...
}

上記が機能しないことはわかっていますが、注釈を @Entity("Bar") に変更するとエラーは発生しませんが、id でエンティティを検索すると、常に null が返されます。

それで...それぞれが同じデータベース/コレクションに同じ方法で書き込むことができるように、2つのクラス構造とMorphaの2つの異なる構成を持つ2つの別々のVMを持つ方法はありますか?

LegacyBar を単に "Bar" に変更し、"com.foo" というパッケージで作成すると、すべてが期待どおりに機能します。私は、このすべてのレガシーデータをセミクリーンな方法で隔離する柔軟性を持っていることを本当に望んでいます.

4

1 に答える 1

4

属性も必要classNameですか？

で無効にできます

@Entity(value = "Bar", noClassnameStored = true)

属性をデータベースにドロップします。

公式ドキュメントの引用：

なぜそれが必要なのですか？ これは主に、異なるエンティティを同じコレクションに格納し、それらを基本クラスまたはスーパー クラスとして読み取るときに使用されます。

これを行わない場合は、異なるパッケージ構造を許可することで簡単に回避できます。

于 2013-10-29T20:49:21.460 に答える