Derek Atkins wrote:
> Presumably the DB can serialize (lock) requests,
> so you don't get intersperced data. But you need more than that.
> In this particular case, User1 got to the DB first, so presumably
> user2 would receive a callback about the change to obj1. However,
> User2 already tried to commit the data.. What's the DB to do?
Hmm, this is the CVS merge problem isn't it?
> No, the UI really needs to be involved in the "lock" mechanism:
> [snip]
> Obviously there are some coherency problems in this model, too. You
> really want an atomic commit operation, but you also want a check for
> coherency as part of the commit.
>
> As I said, it's a challenging problem. But you can't just write it
> off to the DB. The UI has to be able to allow the user to reconcile a
> conflict. Perhaps this is a problem big enough to be put off until
> later. Hrm..
Thank you for your time in explaining this. I am learning just how much I don't
know.
Would something like having user A have the only permissions to change things if
they opened the account first be a usefull first pass. Or is that too simple?
Phill
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
