Gosh has it been 15 years already? I never liked Java much. But several companies I liked and hired me where using mostly that.
Then I did some consulting / freelancing / firefighting. ORM and mostly Hibernate was often a topic.
My experience and methodology is as follow :
- Write test for your ORM layer. Possibly not in Java. Some high level integration type test. ( calling your web-layer or API and checking for what comes out )
- Burn your ORM layer down.
- Have someone who know the business logic sit with you. And re-write the ORM layer from mostly scratch.
- While doing the above, train that person on the very redondant gotcha ( Inverse n to n, accidental carthesian product, bad ID generation, compulsive flush, un-needed @lazy or @eager to deal with performance, @embedded abuse and fucked up SQL schema because of the previous)
- Train all dev on the persistence lifecycle of stuff in JPA. "No, most likely you won't have to call .persist or .merge yourself" being the bottomline
- Have a shiny documented exemple of 1 to 1, N to 1, N to N examples ( both with or without inverse link )
- If some report or API needs a fucked up SQL query with 18 join. Write that thing in native SQL and shove it in your DAO. You don't need to mess up you'r whole DAO layer for those 3 queries
- Pray
- Run the test from step 1.
---
TL;DR : if the ORM layer is somewhat clean. you can mostly forget about it. On the project I'm on now, I did not had to touch it more than once in 2 years. ( and that was terrible, granted, we touched a test and stuff that had nothing to do with it started to blow up. But still, once in 2 years is not a lot )