cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <>
Subject Re: Advice needed: should I migrate from Hibernate to Cayenne?
Date Fri, 12 Aug 2011 17:06:51 GMT
Hi Jo,

Of course the answer is "yes" ... :-)

More seriously, though, to maybe partially answer your questions:

1) We do J2EE here, but pretty much in name only.  We don't do EJBs or
JMS, just web front-end and database back-end.  That seems go cover an
amazing amount of what we need to do.  We are starting to use Cayenne
more and more to talk to the database (Hibernate used to be the
primary choice).  One project is switching mainly due to Hibernate's
LazyInitializationException and the number of man hours it takes to
track those down in a complex web-based application.  Cayenne doesn't
have this exception, even in detached request/response oriented web

2) Do a few pet projects with Cayenne, especially if you don't come
from an Enterprise Objects Framework/Web Objects background.  You will
really want to understand the Cayenne Data/Object Context.  This is a
concept missing in most other ORMs.  Understanding how to use it can
be a big hurdle for some.

3) For me personally, I prefer the non-magic approach, especially when
I need to step through the debugger to figure things out.  Much easier
when you don't go through proxies.  Also, when going through a proxy,
what you think is an instance of a User isn't really ...

4) I didn't fully follow your #4.  It sounds like you may want to
allow concurrent updates, which is generally discouraged.  As for
updating the Order.totalValue, you could override the setter for
OrderDetail.setValue() to re-calculate, but that would also require
all the OrderDetails to be loaded.

5) You may want nested DataContexts here.

6) The amount of work involved depends a lot upon your schema.
Cayenne will give you a good start, usually.  You'll have to go clean
some things up, like your VARCHAR(1) example.  Since you mention
enums, Cayenne does let you map Java enums to arbitrary int/varchar
values (your Java name doesn't have to match the value stored in the
DB).  Say your Order table has a status column and one of the values
is "P" for pending.  You could say in your Java (where OrderStatusType
is an enum): order.setStatus(OrderStatusType.PENDING).  You don't have
to use strings, plus the SQL logging is nicer (shows PENDING gets
mapped to a "P").


On Fri, 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

View raw message