0

I'm working with a legacy database.

I'm using JPA 2.x

I have :

  • a table BUSINESS_ORDER containing domain objects with a PK + a Natural Business Key
  • a table BUSINESS_LEDGER containing domain objects with a PK + a Composite Natural Business Key
  • a table INTEGRATION containing a mapping betweenthe 2 previous tables : a PK + FK_BUSINESS_ORDER + FK_BUSINESS_LEDGER

In my JPA entities :

  • for BUSINESS_ORDER entity, I would like to hide the ID, in favor to expose the Business Key. Exposing business and not the infrastruture key.
  • for BUSINESS_LEDGER entity, same thing. Encapsulate the id and expose a buiness Key
  • for INTEGRATION entity I would like to use the business keys and not the ID. I don't really want to map relationships. Only references because that doesn't make sense from a business point of view. Just keeping the references (business keys) is relevant and useful. The integration entity is for querying and keeping links (like a join table :D)

My question is : how to design the INTEGRATION entity ? I instanciate a new Integration entity, set the Business Keys (order code and ledger code) and save it. During save, the codes are tanslated into their PK and voila. When loading an INTEGRATION entity, the PK is converted to its code.

  • If I don't use the @ManyToOne annotation ;
  • If I use a @Converter, I need to convert from a business key to a PK and need to make a query each time inside a Converter (ewwww). Seems a bit overkill or complicated.
  • If I use a @SecondaryTable (not the default usecase for this annotation). I don't really know how to implement it

Update 1: Perhaps the answer is to use a @Embeddable with a @OneToOne to the ORDER entity for example or a partial vie of the Order entity (only id/code) inside the embeddable.

Archange
  • 397
  • 5
  • 21
  • If it's not too late - "legacy db" and "JPA" most of the time doesn't work together very well. JPA is fine for CRUD, but complex entity relationships + reporting is not its strong suit (not that you can't waste tons of hours to make it work) - so if it's not too late...consider jdbc (via spring-data) or jooq as solutions. – hovanessyan Mar 03 '19 at 09:52
  • Thanks. I'm used to querydsl. I will talk with my colleagues to introduce querydsl for this part. (drawback : yet another technique). In another part I used a Mapper due to the BIG gap between the db schema and the domain model. Here too, not easy to draw the line. – Archange Mar 03 '19 at 10:38
  • Yes, I do believe - producing SQL queries with whatever dsl you want and then leveraging rowmappers will be a good way to go - with high degree of certainty in how the code works and what to expect from the behavior (not the case with JPA if you're not a complete master in the area) – hovanessyan Mar 03 '19 at 11:04

0 Answers0