Here is a backdoor in the JPA spec that gives us one option:
"Note that it is implementation-dependent as to whether PreUpdate and
PostUpdate call-
backs occur when an entity is persisted and subsequently modified in a
single transaction or
when an entity is modified and subsequently removed within a single
transaction. Portable
applications should not rely on such behavior."
Although from a user POV, coupling PrePersist with PreUpdate equals
callback logic insanity :-/
Andrus
On Mar 24, 2009, at 5:21 PM, Andrus Adamchik wrote:
> BTW, I just hit a situation myself, where I must have pre-persist
> called before commit, not in newObject... I guess this is where
> Cayenne is different from Hibernate/JPA - you register an object
> first, then you change it. Not sure how we go about it yet, but now
> I have a full realization of the problem.
>
> Andrus
>
>
> On Mar 6, 2009, at 6:13 PM, Andrey Razumovsky wrote:
>
>> Hi,
>>
>> currently we have prePersist and postPersist callbacks, which are
>> fired for
>> new objects. But the problem is that 'prePersist' callback is
>> called only
>> when context.newObject() is invoked and the data object has no
>> properties.
>> So, since 'preUpdate'is only invoked at modified objects, there's no
>> callback *just before* commit. the only way for me to intercept new
>> objects
>> is in "validateForInsert", but this is certainly ugly. Or maybe I'm
>> just
>> missing something?
>> I suggest that at the minimum we add a new callback ("preInsert").
>> to keep API understandable I find it reasonable to deprecate
>> postPersist
>> and rename it to postInsert.
>>
>> Thanks,
>> Andrey
>
>
This archive was generated by hypermail 2.0.0 : Tue Mar 24 2009 - 11:33:51 EDT