On Sep 7, 2006, at 7:27 AM, Lachlan Deck wrote:
On 06/09/2006, at 5:46 PM, Andrus Adamchik wrote:
Custom values set on the server during commit are not passed back
to the client (except for the PK). It would be nice if they where,
so that's something we may consider doing in 3.0.
Yes please.
But we're not talking about commit are we? I was talking about
init... what happens when creating a new object on the client? Do
any initial values set on the server get propagated back?
Yes, I am talking commit, since commit is the first time when a new
object created on the client is sent to the server. Until then it
sits on the client and server has no chance of participating in its
lifecycle.
What happens on commit is this:
* Client transfers the information about an object as a bunch of
"diffs".
* Server instantiates a server-side object from those diffs.
* Server commits its DataContext.
2) Object modifications
DataContext has event subjects DID_COMMIT, DID_ROLLBACK,
WILL_COMMIT subjects. Great. Where might I find what objects are
available via these notifications?
EOF's delegate has editingContextWillSaveChanges
(EOEditingContext) where if you throw an exception it will abort
the save for the context. How might a listener of the WILL_COMMIT
changes event achieve this? Note: this is not a question about
validateForSave.
DataContextTransactionEventListener and
DataObjectTransactionEventListener are the listener interfaces for
those events. They can abort the commit. Not sure in what form
those will be preserved in 3.0 yet. Also these events are only
available on the server.
How might they abort the commit? By simply throwing an exception?
Yes, since event dispatch is done synchronously in the same thread.
Still like I said, since we want to consolidate events at the
DataChannel level, you should expect some changes (deprecation and/or
removal) of these listeners. You'll have to switch to
DataChannelListener (once an extra subject that I mentioned becomes
available).
Andrus
