Actually EntityManager.persist is the same as
DataContext.registerObject. It does not commit to DB until "flush" is
called or external transaction is committed. But the rest of the
analysis is correct. So I am +1 on the following, even though there
we'll end up with mismatch against JPA (Cayenne.postRegister ==
JPA.prePersist; Cayenne.prePersist != JPA.prePersist) :
> postRegister <- called when a non-persisted object is registered
> with a data context. You could even have a preRegister, but that's
> probably overkill.
> prePersist <- just before DB insert
> postPersist <- just after DB insert
> preUpdate < - just before DB update of existing object
> postUpdate <- just after DB update
> postLoad <- just after a committed obj. is fetched from the DB.
Now wonder what we should do with "remove":
> preRemove <- just before DB delete
> postRemove <-just after DB delete
There are 3 similar lifecycle points: (1) after object is deleted in
context, (2) before deleted object is committed, (3) after deleted
object is committed. Right now "preRemove" is called at (1). For
symmetry we can call it at (2). But then we need another callback for
(1). I just checked some of my use cases, and (1) is sort of an
important place - you can make some assertions about the object before
it is disassociated from its relationships via delete rules. I think I
already figured out how to deal with my case, not sure how such
removal of functionality would affect others?
BTW, if all we do is callback renaming/adding new callbacks, we can
provide DataMap migration ability via the Modeler.
Andrus
On Sep 24, 2009, at 6:08 AM, Robert Zeigler wrote:
> Hm. Apologies, I haven't been following this thread very closely.
> Preface: I realize JPA compatibility isn't necessarily a current
> goal, but hear me out. :)
> The way I read the JPA spec is that..rePersist is supposed to be
> called immediately before database insert.
> The problem seems to be a mismatch between the "cayenne way" and the
> "JPA" way. In cayenne, you register your object, then make your
> changes (especially relationships), then commit to the DB. In JPA,
> you would setup the entire bean structure (including relationships)
> before calling EntityManager.persist, which results directly in a DB
> commit. Ie, persist is like context.registerNewObject() +
> context.commitChanges() rolled into one, except the scope is limited
> a single object and associated changes.
> I don't have any qualms about adding additional lifecycle listeners
> to make cayenne more useful in general and/or to address the
> impedence with JPA, but if we're going to keep lifecycle listeners
> with the same names as the JPA ones, we should also keep the same
> semantics, which means calling PrePersist immediately before
> insert. Otherwise, we'll confuse users new to cayenne but familiar
> with JPA. So, I would propose something more like:
>
> postRegister <- called when a non-persisted object is registered
> with a data context. You could even have a preRegister, but that's
> probably overkill.
> prePersist <- just before DB insert
> postPersist <- just after DB insert
> preUpdate < - just before DB update of existing object
> postUpdate <- just after DB update
> preRemove <- just before DB delete
> postRemove <-just after DB delete
> postLoad <- just after a committed obj. is fetched from the DB.
>
> Alternatively, as mentioned below we could rename all callbacks to
> align with the "cayenne way". But, again, if we're going to keep
> the JPA names, we should keep the behavior as JPA-like as possible.
>
> Robert
This archive was generated by hypermail 2.0.0 : Thu Sep 24 2009 - 06:19:37 EDT