On Fri, Apr 3, 2009 at 5:38 AM, Rickard Öberg <[email protected]> wrote:
> 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
It might not be this simple though. Even for properties these automagic merges
might not be ok. The problem is that your version is per entity state not per
set of properties/associations. So, say you have an entity with 2
properties A { p1, p2 }
at version 0. One process PR1 retrieves A @ version 0 and another process PR2
retrieves it at version 0. PR1 makes a change to p1 and version of A bumps up to
1. Then PR2 makes a change to p2. Is this second change mergeable ? May or
may not be. If p1 and p2 are semantically related it will not be ok,
if not then it
will be fine.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
