On 28/09/2009, at 12:13 AM, Andrus Adamchik wrote:
I am +1 on:
* Radical renaming if that helps us with consistency.
* The observation that pre/postCommit for NEW and MODIFIED objects
are often identical (in my use cases they are always identical).
Wonder in what case it is important to distinguish in postCommit
whether the object was new or modified before commit?
I'm hoping these combined callbacks are not replacing individual ones.
<..>
Conclusion:
So mixing Ari's idea with my points above, we have something like
that:
* postLoad
* postAdd ("post" as it is invoked after object is added to the
context)
* preDelete ("pre" as it is invoked before delete rules are
processed and before the object state is changed)
If you're going that way you'd need a preUpdate to match (wouldn't
you?) to keep it balanced.
* preCommit
* preCommitDeleted
* postCommit
* postCommitDeleted
... or we can go completely the Cayenne way and change the callback
signatures to take an enum characterizing the event nature, or even
some sort of an event object.
Not personally keen on if-else based lifecycle callbacks... but I
suppose everyone's superclass can call the relevant signature.
Just to review the thread.... I'm not sure such a drastic change is
needed to make lifecycle callbacks complete/useful. There was one
(maybe two) missing and some adjusted behaviour / clarification needed
overall, no(?) rather than a complete change?
i.e., it seems to me it's mostly good but with some gaps
postLoad .. after fetch
prePersist ... should be instead called (whether ROP or not) after
validateForSave but before persisting a new object
preUpdate ... as now, after validation and before persisting updates
to an already persisted object
preDelete ... again after validation but prior to deleting from the
objectstore
postPersist
postUpdate
postDelete .. all logically matching their pre counterparts.
what's missing?
postInsert .. called after an object is created and inserted into a
context
So from what I can see the only two changes required were 'postInsert'
and adjusting the meaning of prePersist
with regards,
--
Lachlan Deck
