On Sun, Apr 5, 2009 at 1:21 PM, Alex Shneyderman
<[email protected]> wrote:
> 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,
Agree, but this is not limited to within an EntityState either.
PR1 reads a...@0
PR2 reads a...@0
PR1 updates A.p1 to @1
PR2 update B.p2
Entity B may or may not be in a valid state. And the idea is that Qi4j
should fail the second update, since the 'in-arguments' have been
modified.
So, I am not that convinced of the "merge"-talks either.
In fact, I am getting more and more into the notion that "mutations"
should be placed in stand-alone processes, in a such a way that they
are queueable and re-executable (idempotent).
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
