Kent Sølvsten wrote:
Other persistence framworks separates between the notion of refresh (discarding local changes in the current UoW) and merge (between changes made in this UoW and changes made by other).
Sounds reasonable.
With this terminology I agree that both merge and refresh on a single entity are highly debatable. Refresh() on a complete Uow is the same as tossing it, so that does not make much sense either.
Not quite. If refresh() tosses the state, but keeps the references valid, that still has some merit, as Niclas case pointed out.
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...
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
