QSF progress.

[Derek Atkins]

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
format?

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
-- 
       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