libgda vs. gnucash [was Re: GnuCash page on GO site]

[Rodrigo Moya]

On Thu, 2004-03-04 at 09:24 -0600, Linas Vepstas wrote:

> On Wed, Mar 03, 2004 at 05:35:32PM +0100, Rodrigo Moya was heard to remark:
> > On Wed, 2004-03-03 at 10:24 -0600, Linas Vepstas wrote:
> > 
> > > 
> > > -- an object query system. libgda does not.
> > > -- a uuid system. libgda does not.
> > > -- an object persistance infrastructure. libgda does not. 
> > > -- a multi-user object caching and cache-coherence system. libgda does not.
> > > -- a data-set partitioning system. libgda does not.
> > 
> > We are making progress though. since now we know what you need from
> > libgda. 
> 
> Are you sure you want to implement these features? It wasn't clear
> to me if these were within or outside of your project scope.
> 
it depends, some might make sense in libgda, others, like all data
dictionary management stuff might make sense in libmergeant (part of
mergeant), where a lot of code for that purpose is already available.
Others might go directly to libgnomedb (as I said, most things in
libmergenat will probably be moved to libgnomedb sooner or later)

> > So, next question is, how separated from gnucash are each of
> > those features? 
> 
> Well, I' describing the core gnucash object system.  *if* there
> was another system that really did support all of these features, it
> would not be hard to replace the whole core.  But it would be
> impossible to replace a part of the core.  Each of the features
> is required for the other parts to work correctly.
> 
> > Would it make sense/be not a too hard work to try to
> > integrate them into libgda? 
> 
> I don't know.  It might be hard, there are a variety of subtle 
> issues, some of which we haven't solved ourselves yet.  
> 
> One that has been dogging me is the correct way to split up 
> a dataset across multiple files.  GnuCash startup time takes
> a long time if you have a large data fileset.  So I would like
> to split it up, while still allowing queries over older data 
> in older files if the user needed that. 
> 
you mean like a file per table?

> One problem is that each dataset must have a copy of all of
> the accounts.  When working with mutiple datasets, there is 
> the problem of having what looks like multiple, identical
> copies of the account.  So, we have to be able to identify
> these copies as being "the same account".  On the other hand,
> the newer datasets may have changed/modified the account, so 
> these "identical" records are not really the same.  There's
> a subtle interplay between the UUID's used to identify accounts,
> the possible existance of backups made by the user, and the
> copy-on-write semantics so that we can correctly manage 
> changed/modified versions the objects.
> 
> Derek has been arguing that we supprt SQL only, so that we can
> completely avoid/ignore this issue.  I think I've discovered 
> a simple/easy answer, but haven't implemented it yet.
> 
which answer?

> > or to change them to use libgda for the
> > basic data access and management?
> 
> Can libgda write out XML files? If so, does it need the DTD to do this,
> or does it use schema's?  
> 
libgda can write out XML files, yes, of a custom DTD. We use the DTD
just as a description, we really just write the file directly, with no
validation. Validation could be added, if needed.

cheers