したがって、 Document、Template、およびOriginの 3 つのエンティティを持つモデルがあります。
私の問題の主な原因は、Documentの番号がTemplateのSourceに対して一意である必要があることですが、原点はTemplate
(のではなく) のプロパティであるDocument
ため、一意の制約をまっすぐに作成することはできません・前向きな態度。
明確にするために、コード内のモデルは次のようになります。
元:
@Entity
public class Origin {
@Id private Long id;
// ... some other fields
}
テンプレート:
@Entity
public class Template {
@Id private Long id;
@Column private Origin origin;
// ... some other fields
}
書類:
@Entity
public class Document {
@Id private Long id;
@Column Template template;
@Column Long number;
// ... some other fields
}
そのため、オリジンにはいくつかのテンプレートが関連付けられており、テンプレートを使用してオリジンのドキュメントを作成できます。
前述したように、私の問題の原因は、ドキュメントの番号が各ソースに対して一意でなければならないことにあります。それが機能するために私が考えた唯一の方法は、originIdに追加のフィールドを使用し、それを更新し続けることです。
だから、私はこのようなことをしようとしていました:
@Entity
@Table("documents",
uniqueConstraints = @UniqueConstraint(columnNames = {"number", "originId"}))
public class Document {
@Id private Long id;
@Column Template template;
@Column Long number;
// ... some other fields
// added extra field to use in the constraint:
@Column Long originId;
@PrePersist
@PreUpdate
private void updateConstraintValue() {
this.originId = getTemplate().getId();
}
}
注: getter、setter、およびその他のボイラープレートは、簡潔にするために省略されています
ただし、永続化/更新イベントの時点で Template オブジェクトが管理対象エンティティである必要はないため、JPA では常に機能するとは限りません (関係を機能させるために ID を設定する必要があるだけです)。
それから私は今、これが最善のアプローチではないかもしれないと考えています. だから、私の質問は:
- 他にどのようなオプションがありますか? JPA (または Hibernate) API には、これに対処するためのより良い方法がありますか? (JPA 2 と Hibernate 3.6.10 を使用しています)
- クライアント コードを信頼して、適切な ID を持つ Origin オブジェクトを含む Template オブジェクトを渡す必要がありますか (データベース内のものとは異なる可能性があります)。
- Origin 自体をドキュメントにマッピングし、クライアント コードを信頼してテンプレートとの同期を維持したほうがよいでしょうか?