cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashley Aitken <>
Subject Re: Add ActiveRecord support to Cayenne
Date Sun, 30 Dec 2012 01:34:50 GMT

On 30/12/2012, at 1:50 AM, Mike Kienenberger <> wrote:

> On Sat, Dec 29, 2012 at 8:33 AM, Ashley Aitken <> wrote:
>> Finally, I am also not sure how something like ActiveRecord approach would actually
work, or be compatible with, Cayenne.  To my mind it defeats the whole purpose of having a
container managing the persistence of a collection of objects, not that AR is not an interesting
/ useful approach on its own.
> Having used to actively develop Cayenne applications, but more
> recently having to develop using JPA, which uses an AR approach, I can
> say that it doesn't actually work or help to mix AR and Unit-of-work
> Cayenne DataContext concepts.   You end up trying to imitate a
> scratchpad area using a database transaction, which leaves an ongoing
> open database connection for each DataContext.   JPA entities don't
> have any easy way to be worked on as a group short of an active
> database transaction.

I understand that JPA group actions (e.g. saves) are tied to a database transaction but I
don't see why you feel this is an AR approach?  AR to me is when you call save, for example,
on individual objects etc.  

AR for me is more synonymous with RubyOnRails.  That said, there is apparently an ActiveRecord
implementation for Java, called ActiveJDBC (see Wikipedia).

>> I haven't had anywhere near the experience with large applications / systems as I
am sure many of you have had but I thought the very point of
>> OO was to encapsulate data and behaviour.  As well, the primary purpose of MVC was
to cleanly separate the presentation, application, and
>> domain objects/classes.
> Yes, I've had this argument used against the Cayenne way of doing
> things by coworkers.   What Unit-of-work does is move the level of OO
> from the individual objects being saved to an scratchpad area.   It's
> far more practical to work with a scratchpad of interrelated objects
> than individual objects.   

Hey, I agree with that (though the JPA/Hibernate people would probably say that a context
outside of a transaction is/can be problematic, e.g. as the database changes).  

> Unfortunately, the AR methodology won out,
> and now we have all kinds of issues of not being able to roll back
> groups of changes.   I suppose with some technologies, it would be
> possible to delegate the scratchpad commit and rollback operations to
> the individual objects (I've tried to do this with JPA) but it hasn't
> worked well in practice.

Personally, I agree, having used WebObjects quite a bit with the EOF for object persistence.
 However, in the Enterprise most Java technologies seem (if necessary) linked into JPA.  


Ashley Aitken
Perth, Western Australia
mrhatken at mac dot com
Skype Name: MrHatken (GMT + 8 Hours!)

View raw message