New database backend and multi-user

[Graham Leggett]

Phil Longstaff wrote:

> 1) locking/transactions - db transactions are used whenever an object is 
> written or updated.  However, no locking is done, and there are certain cases 
> where related objects are not saved in the same db transaction, because the 
> back-end does not have enough information.  For example, when a transaction 
> with multiple splits is saved, each of these is a separate engine object and 
> is saved separately.  The back-end API would need to be modified to add "start-
> transaction" and "end-transaction" calls so that multiple objects could be 
> saved/committed/rolled back together.

I would say this is a prerequisite whether multi-user or not. We don't
want an error to happen half way through the save, and the end up with a
corrupt database.

This didn't matter in the XML world so much, as if an error occurred
that corrupted data you were unlikely to get the opportunity to save the
corrupted xml file.

> 2) Update notification - Most objects are read when the db is opened and not 
> read again.  Some databases (postgres? not mysql?) provide a callback when an 
> update is made, so that data can be refreshed.  An alternative would be a 
> timer to refresh.

A far simpler approach is to just react to errors intelligently.

For example, if you have chosen an option from a dialog box, and you
attempt to commit a transaction depending on that option, and you
discover the option you selected in the dialog box no longer exists
(it's been changed, whatever), just tell the user "sorry, conflict,
please make your change again, as the database changed out from beneath
you".

No need for sophisticated error handling, but we do need something more
than the evil message "an error has occurred".

> 3) Mechanism to handle conflicts - How should the cases be handled when 
> different people make conflicting changes?

You simply pop up an error message to the end user, telling them that a
conflict has occurred and they must abandon their changes and try again.

In theory you won't store up a long list of changes, resulting in a big
conflict, you would rather do one small changes at a time, resulting in
small conflicts which are trivial to redo. Small conflicts are also
extremely unlikely to happen, making the pain both small and seldom.

Don't be tempted to offer the end user the option "use my changes and
ignore the conflicted ones", as this is a recipe for pain and angst for
the end user.

Regards,
Graham
--

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3300 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20090907/7bbb2a20/attachment.bin>