> 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
>>
>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Wed Sep 23 2009 - 08:36:22 EDT