Rickard Öberg schrieb:
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.
I think the actual logic to "merge" is completely domain/application specific.
The real problem is to provide a robust and simple API to let the programmer
tell the UoW that the "merge" has happened.
I'm not quite sure but here are my ideas:
1) Merge API: one method readStoredEntityVersionForMerge(): returnes value of
the currently stored entity version and records timestamp. The returned entity
can/might be used by the application to perform the merge. A second method to
signal the UoW that an entity has been merged(). This call checks if there are
concurrent changes again, if not it sets the recorded timestamp.
2) An API to expose the timestamp to the application so that a programmer can
decide *beforehand* if an attempt to commit will throw exception. This of course
is no guarantee that a commit actually will succeed but it would help to signal
the user that a merged needs to be done before the next commit.
What do you think?
-Falko
--
Falko Bräutigam
http://polymap.org
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
