On 8/3/11 18:54 , Falko Bräutigam wrote:
Not that often, but *if* it occurs then it is serious and I "have to"
handle it. The user probably has worked hard and long (maybe 1-2 hours)
to produce the changes. I cannot simply rollback all those changes. At
least I cannot do it without risking to be scalped next time I meet this
user. Which is not an option, at leat in my eyes :)
Ok, so what are the options then?
* If you do EventSourcing, then you can take the currently recorded
events and replay on a new UoW, and you'll basically get a "true merge",
except that some command constraints may be violated (which you
obviously are ok with, since you want a merge).
* Simple state merge. Open a new UoW, load the entities again, and for
any new/updated/removed state, apply that forcefully. Difference to
above is that you have a state approach rather than a event approach.
Biggest issue is that you can get overwrites of partial entity state. It
depends entirely on the domain model whether this makes sense or not.
Of the two, I would definitely go with the EventSourcing approach.
Another variant is to record commands for the UoW instead, and then
replay them on a new UoW, as then all the constraints are checked
properly, i.e. you can never get an inconsistant model. If the replay of
the commands fail, then you really cannot "merge", at least not without
violating some constraints. Recording commands is as simple as putting a
concern on your "command methods" that captures method invocations, and
then put them in a List on the UoW.
Or do you see any other way to do it? It would be nice to have some
standard facilities for this in Qi4j.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
