Timeframes

[Neil Williams]

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 
already? 

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...

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.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- 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/20050915/7af3bc8f/attachment.bin