libgda .... Re: GnuCash page on GO site

[linas linas org (Linas Vepstas)]

On Wed, Mar 03, 2004 at 05:29:59PM +0100, Rodrigo Moya was heard to remark:
> 
> You are saying qof provides you what you need for GNUCash. 

QOF is the internal object framwork inside of gnucash that
is "generic" and is independent of the fact that gnucash deals
with finacial objects.  It is in the process of being split 
out of gnucash.  The split-out is not complete, there are still
important parts that remain inside of gnucash, and haven't
been abstracted yet.

> That's great,
> so then let's see what it's got and how it could be merged/used in
> addition to/whatever with libgda. I guess you are using some API to
> access the databases, am I right? If so, what API(s)? 

The API that we use for database acesss is "QOF". 

> Could those API(s)
> be replaced with libgda, which provides an abstraction over many
> supported RDBMS? What changes would be needed in libgda to allow that?

I've already tried to answer these questions in earlier emails.
I'm trying to be as clear as possible.  We can't replace QOF
with libgda because libgda is missing many features.  

For example, the ability, on the client side, to parse
an SQL statement, and to use the result of that parse to perform
a query over a set of C-language objects, using a 'data dictionary'
of getters and setters to get or set the value of the fields on the 
various C objects involved in the query.

Ideally, the data dictionary should be declarative, not proceedural. 
It would be nice to be able to alter the data dictionary dynamically,
during runtime.

Ideally, the search over the C-language objects should use a
set of binary tree and/or a hash table "indexes", rather than 
a linear search (QOF currently uses a linear search and does
not maintain indexes.).

The API needs to support a cache coherency mechanism, so that
multi-user updates are possible.   So, for example, when the 
query is parsed and performed on the client side, it is traversing
over a set of C-language objects that are stored in the RAM of
the local system.  However, these objects are just a "cache" of
the "real data" that might be in some remote database on another
server.  Thus, if some other user on some remote system makes
changes to the database, these changes should be correctly
picked up in the local client cache.  This cache coherency
mechanism should be as scalable as possible. 

Gnucash/QOF has solved the cache coherency problem by using
the SQL NOTIFY statement, together with an "audit trail" 
stored on the server, so that we know when a cache entry needs 
to be invalidated ("rolled back").  We have no idea how scalable 
it is.  I'm guessing a few dozen simultaneous users are possible. 

--linas




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