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 am -1 on:
* Keeping two parallel sets of callbacks. The only purpose it serves
is compatibility with 3.0MN releases (N <= 6), and the need to
maintain it going forward outweighs it in my mind. Also triggering
callbacks is not free performance-wise, even for those events that
have no registered listeners, so extra callback types will
(marginally) slow things down. This will also allow us to use "pre/
post" prefixes for the names, as there won't parallel conflicting set
of callbacks.
* Mixing pre/postCommit for DELETED with NEW/MODIFIED. The object
state at the end of the commit is different (TRANSIENT for DELETED,
COMMITTED for NEW/MODIFIED), so callbacks are almost never the same.
I am +/-0 on:
* Callbacks on contexts. Could be a good idea to have listeners
attached to a context (although I don't see any use for context's own
callback methods). I suggest we keep that in mind, but push it to the
future releases to avoid adding new concepts to 3.0 at this point.
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)
* 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.
And another idea. Once we settle on the nature of the change on this
list, we write a migration guide draft for the users and take this
discussion to the use..list to see if the wider community can uncover
any holes in the new design, or if there are other use cases that we
haven't thought of.
Andrus
On Sep 24, 2009, at 12:54 PM, Aristedes Maniatis wrote:
> On 24/09/09 6:08 PM, Andrus Adamchik wrote:
>> So I am +1 on the following, even though there we'll end up with
>> mismatch against JPA (Cayenne.postRegister ==
>> JPA.prePersist; Cayenne.prePersist != JPA.prePersist)
>
> Or, to take Robert's suggestion, we leave the existing callbacks in
> place and don't touch them since they are the JPA terms. New stuff
> can have brand new names.
>
> To make a much more radical suggestion:
>
> Working within the context:
> onAddToContext [postRegister at the moment]
> onRemoveFromContext [doesn't exist now, but seems symmetrical]
>
> onDelete [deleted in context]
>
> beforeCommit [preRemove, prePersist and preUpdate together]
> afterCommit [postRemove, postPersist and postUpdate together]
>
> onFetch [postLoad at the moment]
>
>
> If we use words (like "commit") which already have meaning to
> Cayenne users, then it is very clear what is going on and it
> separates them from the JPA words. Then our docs have a little table
> with two columns, showing where our terms match the JPA terms
> exactly and where they differ. Avoiding "pre" and "post" completely
> keeps our terms quite separate. Then we don't even need to deprecate
> the JPA terms at all, just keep them as an 'alias' to Cayenne terms
> where appropriate.
>
> Let me explain my rationale for merging remove, persist and update.
> It is easily possible within the callback itself to determine the
> state of the object, so the user can write code which branches
> appropriately. We find ourselves needing to link both persist and
> update together anyway, because it is likely that the same code will
> run for both. Next, the user action which caused the callback to
> happen was commit(), so it just makes logical sense. Finally, it
> means that the context itself can have its own beforeCommit and
> afterCommit callbacks (with the same names so it all makes
> consistent sense!):
>
> beforeCommit -> object A
> beforeCommit -> object B
> beforeCommit -> context
> ...DB activity...
> afterCommit -> object A
> afterCommit -> object B
> afterCommit -> context
>
>
> This is a bit more work in the modeller to keep both JPA and Cayenne
> callbacks clear, but the end result might be more understandable,
> even if we end up with beforeCommitDelete, beforeCommitInsert,
> beforeCommitUpdate.
>
>
> Ari
>
>
> --
>
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
This archive was generated by hypermail 2.0.0 : Sun Sep 27 2009 - 10:13:17 EDT