Other persistence framworks separates between the notion of refresh
(discarding local changes in the current UoW) and merge (between
changes made in this UoW and changes made by other).
With this terminology I agree that both merge and refresh on a single
entity are highly debatable. Refresh() on a complete Uow is the same
as tossing it, so that does not make much sense either.
But I think that a merge on a whole UoW would be a really nice
feature, sometimes it is really useful to separate stuff between 2
transactions and still allow them to see each others changes.
With a "changeset-based" model, a merge should probably not be too
difficult either.
Med venlig hilsen / Kind regards
Kent Sølvsten
Den 04/05/2009 kl. 04.53 skrev Rickard Öberg:
Hey,
Now that UoW uses event logs as the implementation I am beginning to
wonder what it means to do "refresh" on a UoW. We have talked about
it before but never really reached any concensus.
What does it mean to do "refresh" on a UoW or a single entity in a
UoW? Do we just load the state from the EntityStore and continue as
if nothing happened? But, then it's impossible to know if the state
is valid, isn't it? What if changes has happened in the UoW which
are incompatible with the changes coming from the refreshed state?
Then that would cause the whole system to enter an invalid state!
That doesn't feel right...
I'm beginning to think that refresh should be removed entirely.
Any opinions on this?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
