Thats what I'm trying to say for a while :) It makes it really easy to do scm like entity stores that can also keep the changes forever and can project any version we need. (See also Greg Youngs discussions on DomainEvents etc.)
For the second part of your email (conflicting changes) the Theorie of Patches (darcs) that was mentioned several times on the list holds some solutions (ordering of changes, undoability and axioms around that)
Michael Am 03.04.2009 5:38 Uhr, schrieb Rickard Öberg:
Hey, A really funky side-effect of the ManyAssociation refactorin is that all changes in EntityStore boils down to four operations: * set property * set association * add association (manyassociation) * remove association (manyassociation) This in turn made it TRIVIAL to make all state management change-based rather than state-based. So instead of sending the new state back to the EntityStore we can now send a list of changes. IF the version of the Entity being updated does not match the version in the store it now becomes possible to do merging! Basically, the EntityStore can store the diffs (either infinitely or just "for a while") for a change, and when a change comes in and says "I want to update entity 123 with version 1" but "123" now has version "4" the EntityStore can locate the diffs that caused the version to go from 1 to 4 and do merging with the incoming diff. A simple algorithm would be: as long as the diffs don't change the same property/association/manyassociation it is ok. So even if the version is wrong the change might be accepted. It might even *not* be accepted straight away, but still stored so that an admin can do a visual merge later, in which case the client still doesn't get an exception back. This is really big! :-) /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
