Update: 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) {
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);
}
}
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
=============
http://www.dclug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.williamsleesmill.me.uk/
http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
pgp3Qni9PhEuG.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
