Niclas Hedhman wrote:
On Tue, May 5, 2009 at 9:57 AM, Rickard Öberg <[email protected]> wrote:
Kent Sølvsten wrote:
But I think that a merge on a whole UoW would be a really nice feature,
sometimes it is really useful to separate stuff between 2 transactions and
still allow them to see each others changes.
With a "changeset-based" model, a merge should probably not be too
difficult either.
True, that should be reasonably easy to accomplish. Would we then replay the
events on a single entity so that it is the merge of others changes and ones
own? That could definitely get into an invalid state... the alternative
would be that IF it has changed, then get the others state entirely. Which
could still invalidate aggregate root rules. But with merge(), that's just
how it is...
And I think if merge() exist as an implicit method, we can provide a
MergeResolver (service?) interface for people to hook into for their
particular case, and some simple ones could be provided
'out-of-the-box'.
Could work, yes.
So:
*) refresh() invalidates all EntityState but retains Entity references
*) new merge() operation replays changes from server on local entities,
but only if local has not changed. If yes, then ask MergeResolver for help
*) apply() stays, but with logic as outlined in previous post.
Is that sort of what we're aiming for?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
