QOF-to-SQL Proof of Concept

[Linas Vepstas]

Hi John,

On Sat, May 29, 2004 at 11:26:09PM -0700, John Arrowwood was heard to remark:
> You've got to be careful here.  Some things to ponder:
> 
> In a multi-user environment, you don't want user A to be blocked because 
> user B is trying to do something.  If they are blocked, it should be for no 

The design would remain as it is currently, with locks held for only
fractions of a second (or rather, whatever time a few round-trips
to the server would take).

Note also, the current back-end supports rollback: I hope to smooth out
and simplify that if I can.

> Another thing to keep in mind is the availability of features.  MySQL at 
> one time didn't have transaction support.  Now it does.  Other database 

The locking will be done with an API rather than through straight SQL,
thus anticipating that different DB's may want to do locking in
different ways.

> I suggest a database abstraction.  Have the ability to write 
> database-specific code that is optimized for the way things are done in a 

The current code uses stored proceedures for some things.  I do not yet
know how these will be handled in the future.  The problem is that 
stored proceedures are small, simple, and lightwight.  Replacing 
a 2-4 lines of stored procueedures can take hundreds or thousands of
lines of C code :(

> Or Oracle.  Or MySQL.  Or whatever you want.  And the limitations of the 
> back-end could be completely transparent to the front-end.  The front-end 
> doesn't suffer from the limitations of the back-end.  For example, some 

? There are currently four back-ends, two operational and two in
disrepair.  The ones that work are xml and sql, the rpc and the http
backends are not used and no longer work.  As far as I know, the front
end doesn't suffer from limitations in the backend.

> advantage of the available features of each back-end in order to make it 

That is not how the code is currently written. The front-end remains
ignorant of whiz-bang features in the backend, and we have no machanism
to communicate what these whiz-bangs might be.  Actually, I do not 
see the need for this.

> Now, you may have already planned on doing all of that.  

The backend/frontend architecture in gnucash has been working and
has been more or less stable since 1998.  The upcoming changes will
prove to be the biggest burp to that design since then.

The current postrges code could be generalized to run mysql in about
a week; it was designed to be generalized.   But instead of actually
doing that work, everyone would rather carp about it.  Suggest carpe
diem.

> >lock db
> >do {
> >   check status
> >   if (status changed)
> >      break;
> >   update record
> >} while (0);
> >unlock db

This is how the current postgres backend currently works, except that
there is also code to handle rollback:

lock db
do {
   check status
   if (status changed) {
      fetch updated date from db;
      push it into the front end;
      gui popup tell user that data changed and to review it and try the
              update again.
      break;
   }
   update record
} while (0);
unlock db

Although the rollback feature is only used for transactions and accounts
at this time, and not prices, commodities, etc.  Hope to fix that in the
future.

--linas


-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933