sqlite file format, anyone?

[Linas Vepstas]

On Sat, Jun 21, 2003 at 01:51:56PM -0400, Derek Atkins was heard to remark:
> 
> uggh... yet another dependency!?!  (odbc) If we're going down that
> route we might as well just use libdbi (libdbi.sourceforge.net) which

:-()  libdbi is fine w/ me.  It looks like a cleaned up 
version of ODBC.

FWIW, generic object support might (or might not) require ability 
to handle meta-queries, e.g. 'what are the names of all the tables
in this db' or 'what are the names and types of all the fields in
this table', which odbc supports, and it doesn't look like libdbi does.
(this can be worked around, at least in postgres, which allows things
like 'select * from pg_tables;')

The ODBC 'connection' model stinks, it requires that the user supply 
some sort of convoluted abstracted server/database names instead of 
a simple URL.  Also, the tools to set these up and configure them are 
confusing. Again, legacy of a pre-WWW microsoft design decision.

> is at least lightweight.  RH9 already ships with libdbi-0.6.5 and

Its in debian too, so that's fine by me.  Sorry about the dependencies. 

> Updating multiple tables at once just requires transaction support,
> no?  What else besides transaction support do you need?  

well, for starters, you have to specify *which* tables to update
at the same time: e.g. transaction and split but not account or price or
commodity.   So, from the generic-object point of view, this counts
as 'additional complexity'.   Also, you need to specify how the 
tables are connected, i.e. you have to match guids: 
'update gncTrans, gncSplit where trans.guid=split.guid' so again,
some additional complexity. 

It might be enough to assume that for generic objects, all chaining
together is done with guids.  Also, kvp presents some additonal
complexity.

> Multi-user
> updates is an issue because of how GnuCash caches data in the engine
> instead of relying on the backend all the time.  If GnuCash was
> just a SQL app and didn't cache data locally then we wouldn't have
> this problem, either -- every "refresh" would pull fresh data
> from the database.   Admittedly, I don't know how to do 'events'
> generically in a SQL application.

in postgres, you can broadcast an 'event' which can be any string 
(typically a table name), and anyone 'listening' would get it.

For the sql backend, I added a version number so that every 'refresh'
does *not* go to the db;  it only goes to the db if it received an
event and if the version number changed.  Its not hard per se, its
just that many more KLOC's to write and debug.

Again, that's why the sql backend got so large ... 

> But yea,
> renaming the functions would probably be best, even if it means more
> work keeping everything in sync.  Or you can just write a PERL script
> that does the renaming.  That might be easier.

OK.  Should the prefix be 'qof' or 'gnc'?

I propose using the same capitalization and dash-underscore conventions
as gnome does.  Or do you prefer something different?

Also, its not to late to chage the 'qof' name if you are interested.

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