Multi-user operation (was Re: Query for splits)

Derek Atkins warlord at MIT.EDU
Wed Nov 15 17:40:37 EST 2006


Phil Longstaff <plongstaff at rogers.com> writes:

> On Wed, 2006-15-11 at 13:33 -0500, Derek Atkins wrote:
>> Yes.  Keep in mind that once you get to the point of getting told
>> "object is locked", it's already too late..  There's no error code
>> returned from begin_edit() that could get displayed to the user.  In
>> this case I think it's "last writer wins", but I think that's okay.
>> You could make begin_edit() block until the other client commits the
>> edit on the same object, but that might impose some usability issues.
>> 
>> As for the refresh, yes, you could refresh on begin_edit, but you
>> really should refresh more often than that.  The current PG Backend
>> uses NOTIFY() and events to inform multiple clients that changes have
>> been made.  This isn't portable, so we can't use this method directly.
>> BUT we should periodically poll the database and ask something like:
>> 
>>   select * from Changes where change_time > [last_poll]
>
> I guess what I'm proposing/raising is the idea of another qof API which
> would tell the backend that I want to work on/edit an existing object.
> This would try to lock the object and return a boolean indicating
> success.  GC would call this API for an object when the edit dialog box
> was first opened.

This is exactly what begin_edit() was designed for...  To lock the
database.  The problem is that the gnucash code doesn't use it
in a way where you can notify the user via a dialog if someone else
is editing a transaction..   We don't call this QOF function until
after the user has already started editing.

> This would handle trying to edit an object but would not handle new
> objects i.e. someone else creates a new account.  It's unfortunate that
> there is not a general NOTIFY mechanism which would handle this.  Of
> course, another way to handle the general issue is a GC server.

Blame SQL.

A GC server is not somewhere we should go..  We should handle this
(via polling) on our own.

> Phil

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available


More information about the gnucash-devel mailing list