java - 埋め込まれたIDはjpaからmongoに移動する正しい方法ですか

Question

Long 型の ID を持ち、MySql に格納され、ORM に JPA/Hibernate を使用するオブジェクトが多数あります。将来、一部を Mongo に移行する予定です。ContentId などの Id フィールドに埋め込み可能なクラスを作成し、これをシステム全体で Long の代わりに使用して、MongoDB または Long id のない別の noSql データベースに移動するときに、 ContentId クラス。複合キーに @EmbeddedId を使用することへの参照のみを見つけることができます。これは賢明なことですか？Long を変更して ObjectId に置き換えるときに、1 年ほどですべてのコードを実行する必要はありません。

Answer 1

MongoDB は、生成された OID をデフォルト ID として使用します。_id 属性を使用して独自に定義することもできます。OID は基本的に UUID であり、文字列に最適にマップされます。MySQL で UUID を使用するだけなので、どちらでも同じモデルを使用できます。MongoDB は複合 ID をサポートしていないため、複合 ID を使用することはおそらくお勧めできません。

EclipseLink は、MySQL と MongoDB の両方で JPA をサポートしています。EclipseLink は、任意のデータベースで動作する @UuidGenerator もサポートしています。

http://java-persistence-performance.blogspot.com/2012/04/eclipselink-jpa-supports-mongodb.html

http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/NoSQL

Answer 2

移植性を得るために EmbeddedId が何を提供するかわかりません....利用可能な値ジェネレーターとデータストアがサポートするものに焦点を当て、移行を容易にするために両方のデータストアで何かをマッピングできる方法を探すのが最善です。

DataNucleus JPAは明らかに MongoDB への永続性をサポートしており、しばらくの間、ネイティブ MongoDB UUID (JPA 用語での「アイデンティティ」)、文字列ベース (uuid、uuid-hex)、または数値 ("テーブル"）。これにより移植性が向上し、モデルに最適なものを選択できます。他のデータストアへの移植性も必要な場合は、他の多くのタイプのデータストア (RDBMS、Excel、ODF、ODBMS、HBase、AppEngine、LDAP など) への永続性もサポートします。