Re: Coming from EOF: Cayenne vs Hibernate

From: Robert Zeigler (robert.zeigle..mail.com)
Date: Wed Mar 11 2009 - 16:18:45 EDT

  • Next message: Michael Gentry: "Re: Coming from EOF: Cayenne vs Hibernate"

    On Mar 11, 2009, at 3/113:06 PM , Francisco Peredo wrote:

    >
    > Hi!
    > My first contact with an ORM was EOF... an ever since I have felt that
    > nothing compares to it ;-).
    >
    > The thing is, I have had to work with JPA/Hibernate for a few years
    > now...
    > and I feel it has some weaknesses I really do not like, I am
    > thinking about
    > "switching to cayenne" but first i would like to be sure that
    > Cayenne does
    > not have this weaknesses too.
    >
    > List of weaknesses in JPA/Hibernate:
    >
    > -No way to manage an object that "will be persisted", in JPA/
    > Hibernate if
    > you call entityManager.persist(object) and the database does not
    > support
    > sequences (like MS-Sql) an insert will be triggered, and if any of
    > the non
    > nullable fields of the objects is null, it will crash. If your
    > object has a
    > compound primery key, things get worse, because the entityManager
    > can not
    > deal with it until the compound primary key is set, and if you
    > compound
    > primary key is formed by foreign keys pointing to objects that are
    > new too,
    > that means you will not be able to save stuff with with a simple
    > single call
    > to entityManager.persist to one of the objects, cascading will not
    > help you
    > (I really miss something "magic" like ObjectContext.commitChanges() )
    >

    I routinely: objectContext.newObject(Foo.class);
    or:
    objectContext.registerNewObject(foo);

    with objects that have required fields, etc. Cayenne will mark this as
    an object in state "NEW" (as opposed to transient, which is an
    unmanaged object).
    I've had no issues with compound primary keys which are also FK's.
    (make sure toDepPK is checked on the proper side of teh relationship
    in the modeler).

    > -No easy way to know if "an object is dirty" (if it has changed/
    > deleted
    > since it was read from the database, there is just no API for that),
    > and
    > since you can not know what objects will be persisted, and what
    > object have
    > changed, and what objects will be deleted from database, that means
    > you can
    > not easily create an unified API for centralized polymorphic
    > validation
    > (that is no easy way to create validateForSave, or validateForDelete)
    >

    Sure. You can query the object context for all modified objects.
    You can also directly check the state of an object (MODIFIED, NEW,
    COMMITTED, DELETED, TRANSIENT).
    Of those, only COMMITTED implies that an object is managed, stored in
    the db, and unmodified since it's fetch.
    I've used this to do things like implementing object "histories"
    stored to the db.

    > -No real equivalent for validateForXXX, JPA lifecycle callbacks are
    > not
    > match for validateForXXX because you can not query the database
    > during the
    > lifecycle callbacks, and if you throw an exception inside a lifecycle
    > callback, the JPA/Hibernate entityManager enters an invalid state,
    > and after
    > that you can not continue to use your POJOs, you have to start over
    > with a
    > fresh entityManager... and without you modifications to the POJOs.
    > Note that
    > Hibernate new validation framework does not offer a real solution
    > for this
    > problem... and AFAIK JSR-000303 will not help with this either.
    >

    validateForXXX is supported, including querying into the database.
    I have an app that has an "Enrollment" object with a start and end date.
    One of the business rules is that no two enrollments for a given user
    should overlap.
    So when the object is saved (update or insert), I query the db for
    existing enrollments, and add a validation violation

    > -No support for some kind of temporary id: In JPA/Hibernate, the id
    > for an
    > object is "null" until you flush it to the database, so if you need to
    > reference a particular object instance from the user interface...
    > there is
    > plain no way to do it, you have to "save it first" to get a primary
    > key.

    Yup; definitely an annoyance in hibernate/JPA. Fortunately, cayenne
    objects that are in state NEW /do/ have a temporary id.
    the tapestry5/cayenne integration module takes advantage of this fact
    to do exactly what you mention (referencing a particular object in the
    UI, even if it's new).

    >
    > Those are my main disagreements with the way I have to work with
    > JPA/Hibernate... will switching to
    > Cayenne help me with those? And if it works... here is a crazy
    > idea... what
    > if you guys developed a wrapper that could work on top of any JPA
    > provider
    > to offer a higher level EOF like API ?
    >

    Heh. That's an interesting idea. Seems like we have our hands full
    just developing the core cayenne framework at the moment, though....
    patches always welcome, of course. ;)

    Robert

    > Regards,
    > Francisco
    >
    > --
    > View this message in context: http://www.nabble.com/Coming-from-EOF%3A-Cayenne-vs-Hibernate-tp22463349p22463349.html
    > Sent from the Cayenne - User mailing list archive at Nabble.com.
    >



    This archive was generated by hypermail 2.0.0 : Wed Mar 11 2009 - 16:19:29 EDT