This is causing grief when we need to access relationships of a
deleted object.
Better wording: This is causing grief when we implement a post-update
callback that needs to traverse relationships, and the object is
already deleted, so no relationships are accessible.
On Sep 23, 2009, at 3:32 PM, Andrus Adamchik wrote:
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
