In My Opinion: - the EOF-like conceptual model of Cayenne & Cayenne Modeler was important to me - the OTB Cayenne memory management is excellent - the Cayenne "faulting" behavior is advanced (and leaves one wondering why anyone would choose Hibernate - I think one could call Hibernate faulting-behavior "non existent" if one were to explore this issue in detail) - Cayenne Modeler tool is professional quality and supports reverse engineering as well as an evolving design methodology - the only "advantage" of Hibernate that I have been able to discern is that it is currently "conventional wisdom" among a certain class of project managers who's evaluation process appears to be to evaluate solely based on "conventional wisdom" and then call it a day. I find the "conventional wisdom" evaluation process to be flawed.
Joe On Aug 12, 2011, at 10:36 AM, Durchholz, Joachim wrote: > 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.) > > Regards, > Jo
