sqlite file format, anyone?

[Linas Vepstas]

On Sat, Jun 21, 2003 at 11:00:38AM -0400, Derek Atkins was heard to remark:
> > > SQL generation functions (and maybe even query-response parsing
> > > routines, but that might be harder).
> 
> Basically, generic sql-generation function:
>          gchar * gncFooMakeSQL(Foo*)
> is relatively easy to make.  OTOH, going the other way is hard,
> because each SQL engine provides the data in different formats.
> Unless you can make some assumptions about what you're actually
> getting from the SQL engine.  Can you assume the availability of
> a const char *[]?  I'm not convinced you can...  If you COULD then
> you could create a:
>         Foo * gncFooMakeFromSQL(GNCBook*, const char*[])
> however I do not believe that this is a valid assumption.

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.

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.

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

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