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
