Neil Williams linux at codehelp.co.uk
Fri Sep 16 05:57:32 EDT 2005

On Friday 16 September 2005 7:44 am, Andreas Fromm wrote:
> Derek Atkins wrote:
> >Neil Williams <linux at codehelp.co.uk> writes:
> >>I'd also like to extend the libgda role in QOF to provide more choice of
> >>backends - I see no reason why QOF cannot use SQLite and Postgres +/-
> >> MySQL directly in the same generic manner as QSF.
> >
> >If you DO solve this in the QOF arena, well, it would be nice :)
> >I _think_ it might mean that we don't need to solve it in gnucash..
> >maybe...
> Well the current ( => old ) Pg-backend for gnc has the so called
> "single-user-mode". In this mode no changes on the db are propagated
> to other instances accessing the database.

This probably means that any QOF/GDA implementation would have to almost 
completely replace the gncPg backend. I think gda can be multi-user and it 
provides equal access to SQLite, Postgres and MySQL - others may well be 
added via the ODBC layer in gda (there's even mention of Oracle). It's a 
truly portable, generic, solution.

Having said that, I suspect gda does this by treating each database in the 
same way so some of the reasons for using Postgres over MySQL may not find an 
implementation via gda. I don't know, it's just how it looks at this point. 
Postgres and MySQL are basically gda plugins - I've yet to look at how much 
the plugin can dictate gda configuration and behaviour.

It's yet another layer of abstraction but I hope that it will simply accept 
the QOF abstraction layer as it's own. QOF is sufficiently generic to 
interface with almost any other generic interface. The principle that QOF 
does not care whether the data is a description of an Account or a watermelon 
is vitally important.

Each QofObject would be a table in the QofBook database in one QOF data source 
for that plugin. QOF could support moving data between different plugins via 
GDA but with QSF as a data transport format, I'm not sure that is necessary. 
Each user chooses their data storage by choosing which gda plugin to install. 
A configuration option can set priority if more than one is installed.

GDA-Plugin (Pg, MySQL, SQLite etc.)
	-> single QOF data source - using whichever plugin is chosen.
	-> QofBook database - potentially shared between apps and users.
	-> QofObject tables - one per object in the book
	-> each record in the table = 1 QofInstance

Each table would mimic the QofClass parameters - one field per parameter, type 
dictated by the QofType and field name == QofParam->param_name.

This may involve renaming some parameters that currently use hyphens or 

Applications attempting to load the QofBook would have to use the same 
QofObjects or a QSF-derived map. Those that can load the QofBook "natively" 
keep the same QofBook GUID and can therefore keep their local book in sync 
with the remote database book by only getting the data needed for the current 
operation at any one time, not the entire book (as with file). QOF already 
supports this but the support needs to be tested more fully.

In essence, two applications with the same QofObjects are identical to two 
users of just one application. The application IS the QOF user.

Combine this with the qof-gen role of generating QofObjects from QSF XML and 
anyone can create an application to access their data. It also makes DWI far 
more useful into the bargain.

> Of course this is not what 
> one would ideally expect, but if you know what you are doing.... The
> prospect to have a working sql-backend for gnucash sound very
> interesting to me, and I guess to some other people as well, even if
> it doesn't support multi-user access.

I hope that it will be able to support all that we want. After all, if QOF can 
support two applications in this way, by definition it means that it will 
also support two users of one application in the same way. The application is 
just another QOF user once QofBooks can be shared. Doing this in the gda 
backend also means the file backends continue to operate as now - single user 

Work is some way off just yet, can I ask for your assistance when the time is 
right? (After G2).


Neil Williams

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050916/23974db5/attachment-0001.bin

More information about the gnucash-devel mailing list