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 _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
