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
