Well of course your answer will be Yes :-)
So, more specifically, I'm interested in hearing about the relative strengths and weaknesses of sessionless ORMs, e.g. Ebean.
I'd like to hear opinion, trench stories, and such.
Here's some things I that may or may not be relevant, any feedback welcome:
1. I'm in a J2SE project. There are wishes to convert that into J2EE, or at least partition the J2SE app into a J2EE-compatible service layer and a GUI. (There is also a nightly batch app that I don't see ever arriving in J2EE land. No use case for that.)
2. I can't take any risks. The project is in bad standing already because of all the time (more than a person-year) sunk into identifying and solving Hibernate hassles; another delay on that order of magnitude and I'm out of my current job. I can probably convince my higher-ups to sink another person-month into getting away from Hibernate, but I need to give solid guarantees.
So: any feedback from people who have done that kind of transition would be very, very much appreciated, with a particular emphasis on traps to avoid.
3. I have no LOBs, no wide tables, and all bulk data goes over gigabit ethernet so I don't need no fieldwise laziness.
However, I have no experience with a framework that does not use bytecode generation, so I'm curious how the differences turn out in practice.
So... what do people think about pros and cons of runtime bytecode generation?
4. I'd like to ensure stuff like "Order.totalValue needs to be the sum of all associated OrderDetail.value fields".
"Interesting" aspects here:
- Other applications might have modified OrderDetail records during user think time. I'd prefer the ORM simply updating the totalValue to whatever is in the database over getting a concurrent modification complaint (unless the current app loaded the same OrderDetail and changed the value field to something different).
- The totalValue should get the correct value regardless of whether all pertinent OrderDetails were loaded. (This probably means running an UPDATE statement with SUM(value) in during flush/commit.)
- Various permutation about which fields in Order were modified by the current and the other application, and doing the Right Thing in each case (too much detail for a single post so I'm leaving that out for now).
BTW Hibernate doesn't do this, so supporting that use case would allow me to argue that we're not only getting rid of problems but actually getting something better than initially asked for :-)
5. Those nested transactions (savepoints) are pretty cool and would be a major advantage. Sometimes we do have a series of steps and need to roll back some but not all of them (the "wizard situation").
Are there caveats in that area, or can I go ahead and use that as a selling point without worrying about having to go back on that later?
6. How much manual work is involved in reverse engineering?
For Hibernate, I found that the tool is only marginally better than simply specifying everything by hand. Maybe automatic reverse engineering generally isn't worth the hassle; after all, the tool only sees a VARCHAR(1) but cannot know whether it's just a boolean in disguise or a one-character status code, let alone guess the actual mapping between database strings and Java enum values. (We have lots of such things in our tables.)