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 : Thu Sep 24 2009 - 06:21:05 EDT