QSF progress.

Derek Atkins warlord at MIT.EDU
Fri Jan 7 10:10:17 EST 2005

Neil Williams <linux at codehelp.co.uk> writes:

> As this is in QOF, it doesn't use the GnuCash module interface used for the 
> current XML backend, but instead uses the load_backend_library() routine:
> qof_session_load_backend(QofSession * session, char * access_method)
>  load_backend_library ("libqof_backend_dwi.so", "dwiend_provider_init");
>  load_backend_library ("libqsf-backend-file.so", "qsf_provider_init" );
> defined as:
>  prov->provider_name = "QSF Backend Version 0.1";
>  prov->access_method = "file";
>  prov->backend_new = qsf_backend_new;

I'm not sure what this means, but I guess it sounds ok to me.  We
should probably just change everything to use gmodule anyways. ;)

> I've got routines based on schema validation that can discriminate between 
> current GnuCash XML (bin, v1 and v2) and QSF XML, suitable for use in 
> gnc_file_be_determine_file_type and gnc_file_be_load_from_file or elsewhere. 
> The schema validation is used before loading QSF, before writing QSF and in 
> determining how to load the QSF (with or without maps) - it's this that 
> requires libxml2 >= 2.5.2 - and will mean that QOF will never write an 
> invalid QSF file and will bail out (with a few libxml2 messages and suitable 
> QofBackendError values) if an invalid QSF file is selected for import.

Excellent!  Hopefully this can eventually also add the SQLite file

FWIW, requiring libxml2 >= 2.5.2 shouldn't be a problem.  Even RH9
(updates) distributes 2.5.4, and FC1 uses 2.5.11 by default.  So I
don't see this as a problem.

> The QofBook from the QSF file can then be merged using qof_book_merge.
> I've fixed the design problem with qof_book_merge relating to static 
> definition of the merge context. It works fine in testing but I've still got 
> more to do with druid_merge.c - it merges OK but then GnuCash seg faults when 
> saving the file because of an error generated in xaccGroupGetNumSubAccounts.
> The code responsible is probably:
> void currency_transfer_cb ( QofEntity* ent, gpointer user_data)
> {
>         if(!ent) return;
>         if(xaccAccountGetCommodity((Account*)ent) == NULL) {
>              xaccAccountSetCommodity((Account*)ent,gnc_default_currency());
>         }
> }
> void reference_parent_cb ( QofEntity* ent, gpointer user_data)
> {
>         if(!ent) return;
>         if(xaccAccountGetParent((Account*)ent) == NULL) {
>            xaccGroupInsertAccount(xaccGroupGetRoot(xaccGetAccountGroup(targetBook)), 
> (Account*)ent);
>         }
> }

I don't see anything particularly wrong with this -- except how would
it deal with Scheduled Transactions, which have Account objects that
don't live in the Book's AccountGroup?

       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list