cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Baldwin <jfbald...@earthlink.net>
Subject Re: Advice needed: should I migrate from Hibernate to Cayenne?
Date Fri, 12 Aug 2011 15:37:49 GMT
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


Mime
View raw message