Re: GnuCash page on GO site

On Thu, Feb 26, 2004 at 02:06:34PM +0000, Charles Goodwin was heard to remark:
> On Thu, 2004-02-26 at 05:13, Linas Vepstas wrote:
> > My gut feel is that libgda offers the wrong abstractions. 
> > Although gnucash data can be (is) represented as SQL, that's 
> > the wrong place to work.  There's a lot of pulling things together
> > that must happen before the data is reportable.  For example,
> > computing account balances can be quite complicated; its not a
> > simple sql query or a simple table lookup.
> 
> Call me stupid but isn't libgda a data abstraction layer?  Does the data
> initially have to be SQL or can it not be some arbitrary format which
> libgda supports?  Could this be as easy as adding GnuCash-data-support
> to libgda?

? Not last time I looked. I argued this with rodrigo and many others
over the last 3-4 years, and I went off and created dwi out of
frustration.  treshna created bond out of frustration, and I think the
gnue guys went thier own way too. For the gnucash engine, we implemented
'qof' to solve that need.  Actually, qof is older than gnomedb, 
Derek's re-write of qof is now the 3rd rewrite of the query engine.  
I don't think libgda even *has* a query engine.  

I'm looking at the libgda docs, but if they have data abstraction,
then I can't see it documented anywhere.

In my most recent adventure, I was intellectually contemplating
gluing the gnucash qof to the bottom of SQLLite.  sqllite does
support a limited amount of abstraction, I think they even have 
some sample code showing how to use sql to get the free disk space 
and cpu temperature.   I thought that would be pretty cool.

Derek, I'm not sure I ever mentioned/explained this: *if* we 
glue gnucash objects to the *bottom* of sqllite, then we can use
standard SQL queries to get data out of them.  Then people like
libgda and gnomedb and other report systems could sit on top of 
the sqllite api, and do whatever they need to do.  Yes, this is 
very hypothetical right now, and there are some dangerous 
unexplored issues.  It wasn't something I'd wanted to do soon,
just maybe someday.

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[email protected]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933