linux at codehelp.co.uk
Thu Sep 15 12:29:34 EDT 2005
On Thursday 15 September 2005 4:27 pm, 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.
> Adding a database backend adds overhead in terms of cache coherency.
> You need to make sure that multiple QOF applications running against
> the same SQL database maintain the same cache of QOF objects in core.
> That way when one application makes a change to the database the other
> application sees the change. This would be _expected_ in a sql backend.
> It's not expected in a file backend.
> Just keep this in mind.
Thanks - this strikes me as a problem someone else must already have solved
but I haven't even looked at the complexity of it yet, it's just that linking
against libgda makes it a possibility.
Do you know of another free software package that might have done this
It looks like gda may have this available - applications (i.e. QOF in our
case) can request a unique provider or share a provider. It should be
possible to have only one unique provider for all QOF processes which means
that those QOF applications that use the same QOF objects will share the same
GDA data stream.
i.e. pilotqof has pilot_* objects in the one QOF data source.
cashutil has gnucash objects in the same QOF data source which are independent
unless specifically converted (and QOF could support such conversion).
gnucash has the same objects as cashutil in the same data source and can
therefore read the same books.
If two applications open the same book from the one data source, then QOF
needs to simply pull the data from the data source each time - yes? Let GDA
deal with the complexity? After all, a book has a GUID to uniquely identify
it. Using the existing mechanisms, we should be able to only pass those
pieces of data that are required for the current operation - when those are
committed, they will be available to another application.
I've joined the gda list to try and work out if this would work.
> If you DO solve this in the QOF arena, well, it would be nice :)
Don't hold your breath! However, this would add Postgres, MySQL, SQLite and
other backends in one operation. Plus, ANY new QOF objects would be instantly
supported by ALL backends with no extra code.
I would be surprised if I can do this alone - and I can't even start looking
at it in detail until QOF 0.6.0 is out and work can start on 0.7
> I _think_ it might mean that we don't need to solve it in gnucash..
Maybe - but I think it's only *really* likely if the current gnucash database
developers and those working on SQLite take it on board. Otherwise although
it would be nice to have, it may simply duplicate their work. After all, this
will be a QOF backend, not a GnuCash backend so the data descriptors will be
more akin to QSF than to the gnc file backend. I'll be talking about objects
called "gncInvoice": <object name="gncInvoice"> compared to <invoice> and all
data would be stored only via QOF parameters, not bespoke handlers that need
to be re-written if the object description changes.
-------------- 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/20050915/7af3bc8f/attachment.bin
More information about the gnucash-devel