On 24/09/2009, at 6:14 AM, Andrus Adamchik wrote:
> Hi Andrey,
>
> Thanks for your comments. This made me tweak my initial suggestion,
> resulting in something that hopefully makes more sense. So here is
> an attempt to show the full callback picture with suggested changes
> (grouping things by the object pre-commit state):
>
> COMMITTED:
> postLoad
>
> NEW:
> prePersist (called after registration in context)
> preInsert (POTENTIAL NEW CALLBACK; called before commit) [1]
> postPersist (called after commit)
The naming of these is a little less unintuitive though. What about:
postInsert (called after registration in context)
prePersist (called just before commit, but after validation)
postPersist (called after commit)
This - naming-wise - would fit better with the modified callbacks, no?
> MODIFIED:
> preUpdate (called before commit)
> postUpdate (called after commit)
>
> DELETED:
> preRemove (called before deleting in context, and before delete
> rules are evaluated)
> preUpdate (POTENTIAL REMOVED CALLBACK; called before commit) [2]
> postRemove (called after commit)
> postUpdate (POTENTIAL REMOVED CALLBACK; called after commit) [3]
>
>
> [1] We definitely need this callback here for the new objects right
> before commit. My suggestion of reusing "preUpdate" here was based
> on the fact that all my pre-commit code for NEW and MODIFIED objects
> is exactly the same, so it seems that from implementation standpoint
> the event is almost identical. On the other hand, "postUpdate" is
> indeed redundant for NEW objects. So using pre/postUpdate for NEW
> does break the symmetry...
>
> [2] While there's no overlap with a real "preUpdate" in possible
> callback functionality here, and we need to remove this one, this
> leaves a gap (just like with NEW objects) that needs to be filled
> with some "preCommitDeleted" callback.
>
> [3] Definitely needs to be removed. It is being passed TRANSIENT
> objects and is really out of place (though still JPA compatible :-)).
>
> I guess completely renaming callbacks to be aligned with Cayenne
> (rather than JPA) lifecycle could be a good thing (persist -> insert|
> create, remove -> delete, etc.), and may go a long way in clarifying
> what is called and when. It is the end of a long day here, so I am
> not ready to suggest any better naming right away, but regardless of
> the naming, if we just make the changes above, I think we can
> provide the existing users a clear set of instructions on how to
> migrate existing callbacks to the new set. FWIW I'll be able to try
> it myself on a large application without waiting for the B1 release.
>
> Andrus
>
>
>
> On Sep 23, 2009, at 8:53 PM, Andrey Razumovsky wrote:
>
>> Hi Andrus,
>>
>> I also suffered missing "preInsert" listener a number of times.
>> But, I think
>> the moment of when listeners are called (and which of them are
>> called)
>> should be easily guessed by what is happening to the object.
>>
>> 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.
>>>>
>>>>
>> So there will be four calls in total at object creation. I don't
>> think it is
>> transparent that pre- and postUpdate will be called - after all, no
>> updates
>> are ever made!
>>
>>
>>> 2. stop calling pre/postUpdate for removed objects. This is
>>> causing grief
>>>> when we need to access relationships of a deleted object.
>>>>
>>>
>> I'm confused. Are pre/postUpdate methods really called for deleted
>> objects?
>> If this is so, it definitely must be stopped I think. Only pre/
>> postRemove
>> should be called..
>>
>> What will be wrong if we just add new type of event - preInsert?
>> Users
>> aren't obligated to implement any listener class, after all. I'm
>> afraid the
>> changes you suggest will break a lot of existing code
>>
>> Thanks,
>
with regards,
--Lachlan Deck
This archive was generated by hypermail 2.0.0 : Wed Sep 23 2009 - 20:15:56 EDT