sqlite file format, anyone?

[Derek Atkins]

linas at linas.org (Linas Vepstas) writes:

> I'm still not sure I understand, but I think many/most of the issues
> you are concerned about are taken care of by ODBC API.  There are two
> main versions of ODBC for linux, the better one connects to most linux
> db's as well as MS-SQL (and presumable oracle, etc. etc.)  The ODBC
> programming interface is rather ugly, coming as it does from the 
> demented Microsoft Windows API camp.  But for the most part, it does 
> work and it does do the things you want it to do.

uggh... yet another dependency!?!  (odbc) If we're going down that
route we might as well just use libdbi (libdbi.sourceforge.net) which
is at least lightweight.  RH9 already ships with libdbi-0.6.5 and
contains both a pg and mysql driver.  Admittedly it might not be the
embedded-mysql driver, which is why I've been hesitant in the past.
The API for libdbi looks REALLY useful and does address pretty much
all of my issues.  In particular, see dbi_result_get_fields() at:

  http://libdbi.sourceforge.net/docs/programmers-guide/reference-field.html#DBI-RESULT-GET-FIELDS

> There are some meta-level issues that are hard.   One reason the 
> gnucash postgres backend is so large and complex is that I wasn't 
> prepared for these.  I thought that I could simply map objects to
> tables and back, and that was it.  The meta-issues turned out to be
> related to locking, the need to update multiple tables at once 
> in a consistent, ACID-type way.   There are some other issues 
> I stumbled over, that I don't quite (want to) remember.  Multi-user
> updates was one -- the event generation to let other users know
> that the db changed.

Updating multiple tables at once just requires transaction support,
no?  What else besides transaction support do you need?  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.

> > > p.s. I have a strong urge to rename everything in the QOF module into
> > > a consistent naming convention. I have an exactly counterbalancing sense
> > > that this is a waste of time.  Comments?
> > 
> > Do you ever expect an application to link against GnuCash *AND* QOF
> > at the same time?  What about an application linking against GnuCash
> > and another library built with QOF?
> 
> Don't know. Maybe. When I get done QOF-ifying GnoTime, then in theory
> gnucash will be able to link to it and talk to it 'natively'.  But this
> raises a whole new set of issues.  One at a time ...

I think "bonobo" (corba) might be the right thing here.  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.

> --linas

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available