On Fri, Apr 17, 2009 at 10:18 AM, Rickard Öberg <[email protected]> wrote:
> Load Entity 123 with x=1,y="Foo" > Change x->3 > Refresh 123. x had been changed to 5 and y to "Bar" > Replay events for 123 > Entity 123 now has state x=3 and y="Bar", i.e. the merge between the new > state and the updated local state. > User is happy and completes() UoW > In store that data is now: 123: x=3, y="Bar" Hmmm....??? I am skeptical... mostly since I don't think that real cases are this neat and can be easily understood. I am more concerned over 'cause and effect'. Setting x->3 above could very well be due to the fact that y="Foo". How is that handled? Then it is nothing related to merge, but running through the code again (unless the mutation code are small objects that are put into the UoW, as discussed previously). And since we need to support that, the 'merge' case is barely needed. Providing the 'merge' facility may even cause more damage to our reputation, since it might be overused and causing inconsistencies all over the place (esp if run 'automated' without user interactions), easily blamed on a 'flawed Qi4j model'. 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
