Cloud options?

[Jean-David Beyer]

On 09/10/2013 10:39 AM, Buddha Buck wrote:
> On Tue, Sep 10, 2013 at 10:08 AM, Mike or Penny Novack <
> stepbystepfarm at mtdata.com> wrote:
> 
>> Correct. While gnucash allows consecutive multiple users it does not allow
>> simultaneous multiple users.
>>
>> To provide THAT wouldn't be a simple matter for gnucash developers nor
>> would it be simply a matter of changing gnucash itself. For an application
>> to allow multiple simultaneous users requires a DBM (database manager) for
>> the program to run under as well as a data being kept in a database that
>> this manager handles. Well SQL qualifies for THAT but I don't know if there
>> are any open source projects out there providing a DBM for that.
>>
> 
> There are plenty.  MySQL, PostgreSQL, others.  MySQL is GPL2, PostgreSQL
> uses it's own modified MIT license.  Both are in heavy use, and would meet
> the "multiple simultaneous user" requirement handily.

Red Hat distribute MySQL (I think) and postgreSQL (for sure), for their
RHEL 3, 5, and 6 releases. Probably release 4 as well, but I never tried
it on that. So it is open source enough for them, and the postgreSQL
license, whatever it is, must be broad enough that they are willing to
include it in their distribution and support it.
> 
> Asking the gnucash developers to roll their own DBM is too much. A DBM
>> wouldn't be specific to an application (though all applications using it
>> would need adjustment to run under its control). So THAT is the question we
>> need to ask, IS there a project to provide a "free" DBM"?
>>
> 
> As above, a "free" DMBS isn't the problem.  The problem is the "would need
> adjustment to run under its control" aspect.  This is probably getting a
> bit far afield for the gnucash-USER list, but as I understand it GnuCash
> keeps all data in memory, loading it in when the application starts and
> writing it out when saving (or autosaving) the data.  It does not read the
> data from the file when opening a register, viewing an invoice, generating
> a report, etc.  It does not write the data to the file when saving a
> transaction, editing an invoice, creating an account, etc. In order to do
> true multi-user, it would have to be modified to do so (or at least, to use
> a data abstraction layer that could be configured to do so). That is a lot
> of work that goes right at the heart of how GnuCash manages data.
> 

I do not understand what you are saying here. I know the present
implementation of gnucash (as I understand it; i.e., not very well) it
uses the dbms as just a means to read and write the entire database.
This would not be ideal if dbms users wanted to do anything with the
database. For that it would need the data structure to be defined as a
group of normalized tables, not just one big table.

It would also need the gnucash program to operate on the database as a
bunch of transactions. I imagine that will be a very-long term goal for
the project, but it would be very difficult. I.e., almost as hard as
re-writing a hunk of the program from scratch. Hence the delay.

But assuming that is done, you would need no more dbms changing. I do
not know what you mean by "control aspect."

It could work like this:

Each user could have both read and write permission on the database
(concurrently). Only one user at a time would have write permission on
the database, but all the others could have read permission. All users
would get a consistent view of the database, but it might not be the
most up-to-date. Many users can accept something like this. They are
just getting reports.

For write or update transactions, what would happen depends on just how
fine the locking of the database is. The worst way would be to lock the
whole database; i.e., one person could write or update, and the others
read only, until the writer closed the database. This is usually
considered unsatisfactory. Often locks are much finer and only the
records read by a program are locked when a transaction starts (assuming
it might write or update them) and they are either committed and locks
released when the transaction is committed or aborted.

This would be pretty much ideal. The exact details I have left a bit
vague because they differ from one dbms to another. And as I said
earlier, to change the fundamental idea of processing the database as
transactions rather than just wholesale reads and writes is a tough job
for which I do not envy the developers at all.


-- 
  .~.  Jean-David Beyer          Registered Linux User 85642.
  /V\  PGP-Key:166D840A 0C610C8B Registered Machine  1935521.
 /( )\ Shrewsbury, New Jersey    http://counter.li.org
 ^^-^^ 21:20:01 up 13 days, 4:04, 3 users, load average: 4.75, 4.51, 4.44