QSF progress.

Neil Williams linux at codehelp.co.uk
Thu Jan 6 18:47:46 EST 2005


I've got the QSF QofBackend to a functional condition and just tonight I've 
got a test routine to work with the new code.

First stage is to load native QSF objects - those written and loaded by the 
same QOF application, then I can get back to the maps - for data that is 
converted between applications.

The test routine can demonstrate how to:

1. Load an empty session and set the QSF Backend with the empty QofBook.
2. Create QOF objects (defined in the test routine) and set some test data.
 (the test objects come directly from test-book-merge)
3. Write out those QOF objects as a valid QSF file in /tmp
4. Close that session and start a new one (lose all QOF data from memory)
5. Load the QSF file from /tmp and load the new QofBook with data from QSF
6. Convert the QofBook BACK into XML for display on the terminal.

I think that's most of what we'd need a backend to perform!!

6. is only needed for test purposes.

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

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

void reference_parent_cb ( QofEntity* ent, gpointer user_data)
        if(!ent) return;
        if(xaccAccountGetParent((Account*)ent) == NULL) {

Called using:
   qof_object_foreach(GNC_ID_ACCOUNT, targetBook, currency_transfer_cb, NULL);
   qof_object_foreach(GNC_ID_ACCOUNT, targetBook, reference_parent_cb,  NULL);
on the newly merged QofBook.

Any clues/fixes welcome.

There are other improvements that can be made to the merge code too.

The QSF and merge code has been committed to QOF CVS - tonight's test routine 
won't be committed now until tomorrow evening (paid work commitments) - and a 
qof_book_merge patch for GnuCash will follow, hopefully this weekend.

It'll be a little longer before QSF makes it into GnuCash - I'll need to get 
used to the gnome2 branch - QSF will require libxml2 >=2.5.2 - but I'm now 
concentrating on getting the maps working, getting pilot-link to use QOF as a 
framework and then building QSF into g2.

Hey ho. busy, busy.


Neil Williams

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050106/fee1b0ff/attachment.bin

More information about the gnucash-devel mailing list