Niclas Hedhman wrote:
You seem to have the notion that changes are direct human input. I would like to contend that this is just one of many minority cases (as I doubt there are any majority cases).
Yes, speaking of minority/majority with this stuff is not very meaningful.
For a mixed human-machine mutation, 'playing events' is not acceptable, and 'redoing everything' is annoying to the user. In the other post you mention; refresh(); vs merge(); So, let's talk about them for a second. refresh() in the currently proposed system can actually become quite an exercise. 1. BASE principle will dictate that reading the store is not necessarily going to resolve the ConModExc.
True, and depends on whether getEntityState() can be expected to get the consistent state or not. This is where the CAP settings come in I think, as we can force the getEntityState() to be consistent by setting CA (refresh and block until done) or CP (refresh and throw exception on network error).
2. Reading through the /changes is a slow process and possibly very expensive (CPU and/or I/O).
Yeah, I would not suggest that clients do this directly. Using getEntityStore with a CA/CP setting would be better.
3. Waiting for the read-store to get populated is slow, but not expensive. merge() is then suggested to be something that the client code can indulge itself in. The challenge then would be how to report conflicts, just like your regular SCM tool, and also keep the conflicts marked as such until resolved. IMHO, a blind merge() with auto-resolve is very dangerous, and hard to debug (intermittent problems in a runtime environment, and near impossible to replicate) and I would like it not to exist at all in such case.
Maybe. And yet this is similar to how SiteVision works and I am not aware of any time where it has caused problems. Are there theoretical cases where it could go wrong? Sure, I'm just saying so far it hasn't, and for me that's good enough for that kind of application. If consistency is more important, then you have to do more work to resolve conflicts.
But taking a step back: what resolution protocols do you see the client doing if we don't have refresh() and/or merge()? Or is it just merge() that is the problem here? What are acceptable ways to do it? Annoy the user by rolling the whole thing back is secure but not a good user experience.
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
