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..
> 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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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