JPA 按实体或 Id 映射 OneToOne

Question

What is the reason of following mapping?

  @Column(name = "inspection_platform_id")
  private Long inspectionPlatformEntityId;

  @OneToOne(fetch = FetchType.LAZY)
  @JoinColumn(name = "inspection_platform_id", insertable = false, updatable = false)
  private InspectionPlatformEntity inspectionPlatformEntity;

Why do we need to specify mapping for foreign key if we specified mapping for whole entity and we can easily extract ID from that entity.

I have a suggestion that this is due to lazy loading so we do not need to fetch the whole entity just to extract it's ID, but I also seen this approach with EAGER fetch type so I don't understand the reason

Answer 1

Reasons to do so:

• JPA dot notation '.' over a relationship in JPQL specifies an inner join, or you have to explicitly define the join to be left out join.

Some providers might optimize and understand "Select entity from Entity e where e.inspectionPlatformEntity.id =:value" does not require a table join, but you are at the JPA provider's mercy, and would have to understand which side of relationship the FK exists on. Having basic mappings makes it more clear and allows you do define precisely what you want if you need to.

• Serialization. You may want to have the ID serialized elsewhere in some situations, but not require the object be serialized. When writing out this object, because the join column for inspectionPlatformEntity is insertable/updatable=false, you don't need this referenced object serialized with this entity all over the place.

• This makes batch updates more efficient, so you don't need to fetch a bunch of InspectionPlatformEntity instances to check if they exist and need updating. I can leave that relationship as null and JPA will just ignore it, lazy or not.

• refactoring. Our devs don't know if they need the reference or just the FK value. Having everything go through that reference object forces me to always have it loaded where they need it. Giving them the FK value gives me the option to load the references in some use cases, or get them to look it up using the FK value for others. They don't need to know what is more efficient for their use case when they are writing it, and we can go out to testing before determining what should be done.

• caching. As per above with serialization, I may need to cache this entity and in some cases want the referenced entity cached with it, or in some object graphs, the ability to null it out without losing knowledge of the relationship still existing.