Having run into some issues with callbacks myself and generally gaining better insight into callbacks patterns, I second what Ari has suggested two years ago in the message below. Namely I suggest the following changes:

1. call pre/postUpdate for new objects. So new objects will have pre/ postPersist as well as pre/postUpdate callbacks. Of course the main motivation is that preUpdate is called before save, not after context insert, so all the relationships are in place.

2. stop calling pre/postUpdate for removed objects. This is causing grief when we need to access relationships of a deleted object.

Both changes are actually still compatible with JPA spec, due to the vagueness mentioned below. This may affect the callbacks currently in use by 3.0 applications, so this is our last chance to slip it in before the beta, and also we need to make it clear what upgrade steps need to be taken by the current 3.0 users.

If there's no objections, I will work on such change.

(Also not sure how this affects ROP yet?)

Andrus


On Nov 29, 2007, at 10:56 AM, Aristedes Maniatis wrote:
On 29/11/2007, at 12:28 PM, Aristedes Maniatis wrote:

Summary
-------

* prePersist() is only useful as a place to set object attributes (such as creationDate) since you cannot follow relations reliably in a ROP environment.

* postUpdate() and postPersist() are useful for changes which do not need to be committed atomically with the original commit. So good for creating log records, but not ideal for updating invoiceOwing.

* postPersist() is badly named. It is really postInsert()

* we need preInsert()


With some further reading of the JPA specification I have come to the following conclusions:

* the JPA was written by lawyers who get paid by the word

* postPersist() is defined in the JPA to occur after a NEW record is written to the database. Which is how Cayenne works.

* pre/postUpdate(): the JPA specification is very very unclear, but it looks like maybe it might apply for both new and existing records. But then postUpdate() overlaps postPersist() which is a bit pointless.

* if preUpdate() is just for existing records we still need a preInsert().


So, even though we have to follow the poorly named callbacks in JPA, an extra callback would fill a useful hole.


Ari


-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A




Reply via email to