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!)

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 35 of 36 | next ›
Discussion Overview
groupuser @
postedDec 17, '12 at 11:09p
activeDec 30, '12 at 1:51a



site design / logo © 2022 Grokbase