QSF Import of gncCustomer and gncAddress Issues (and partial
success)
Georgi Mirchev
manager at mirchevideas.com
Mon May 29 13:47:39 EDT 2006
Hi,
I'm not sure when I'll be able to write the code. I'll probably file a
bug report.
There is one thing that I'm not sure how to implement, maybe you can
give me some pointers. Here is the problem:
When new gncCustomer is created the constructor automatically creates 2
gncAddress objects, for the addr and shipaddr properties. The two new
gncAddress objects are registered with the book given to the constructor.
If a new addr or shipaddr is set the setter function destroys the old
gncAddress object by calling it's destructor. But the object is NOT
removed from the book. So we have pointers to already freed data. The
import hits this condition because it imports gncCustomer, then
gncAddress and then sets the gncAddress object into gncCustomer,
effectively replacing the old gncAddress object. But the old gncAddress
still stays in the Book.
This is exactly what happens upon import, often making QSF import very
unstable.
There are several variants:
1. The gncCustomer should not autocreate two gncAddress objects.
2. The destroying object deregisters itself from the book it is (do we
know for each object which book it resides? can one gncAdress live in
more than one book?)
3. The code that calls the destructors should remove the object from the
book. There might be a problem, since we are not sure if we should
remove the object from the book first, or destroy the object first. This
is in case the removing from the book requires more than a pointer, or
the destructor assumes the object is in the book.
And maybe the solution is 1. plus one of 2. or 3. Please advise.
Since the QSF Import/Export is disabled in the head, how to reenable it
for testing?
Regards,
Georgi
Derek Atkins wrote:
> Hi.
>
> We've disabled QSF Import/Export for now because that subsystem is
> still very unstable... Too unstable for the upcoming stable release.
> But yes, you can send patches here. "svn diff" is good enough. Your
> other options is to file a bug report and attach your patch to the
> bug report. That's less likely to get lost than an email message.
>
> If you plan to send it soon, I'd recommend a bug report, because I
> dont think we have plans to patch QSF prior to the 2.0 release.
>
> -derek
>
> Quoting Georgi Mirchev <manager at mirchevideas.com>:
>
>> For the last days I have been trying hard to make gnucash import QSF
>> data, in native format (i.e. without mapping, just the raw QOF
>> objects). The data I wanted to go first with is a single customer
>> record. The customer has an address record.
>> Let me state that I had A LOT of problems. Here are a few comments of
>> my way of handling things, bug reports, the success report, and
>> improvement suggestions.
>>
>> Please note that this is the first time I'm reading all this QOF/QSF
>> code, so I might be wrong here or there.
>>
>> First I took vcard-gnccustomer.pl, and extracted only the XML
>> structure out of the source, so that I can write my own XML file with
>> one customer, with their address. I checked that it is well formed,
>> and read the DTD, so that my XML file is ok with it. Onwards. I went
>> to import the file. And I got error that the file cannot be imported,
>> no error code, no error description. Very informational :-) An hour
>> later I found that the QSF file backend actually returns error codes,
>> in the form of random and non-unique negative numbers. So I changed
>> them to other random, but at least unique negative error codes, and
>> modified the error message to include them. Voila, I get an error
>> code :-)
>>
>> My happiness didn't last long, since the code didn't help me at all.
>> Suffice to say that a few hours later I found out that the QSF
>> backend returns well specified error codes, and keeps a stack of
>> them. Why, the heck (I wanted to put something else here, but I'm
>> worried the message will get censored), these codes don't get passed
>> to the wizard and the wizard doesn't print informative error message.
>> In my case the problem turned out that I have empty GUID for the
>> book. I took this code from vcard-gnccustomer.pl, so as a side note,
>> this perl file doesn't generate valid QSF files.
>>
>> SUGGESTION: Make QSF import wizard print informative error messages
>> based on error codes returned from the QSF backed.
>>
>> So we are in the wizard now. Import successful. Checking what we have
>> imported - customer is there, address is empty. Halfway I thought. I
>> couldn't been more wrong. It took 5 times more time to figure how to
>> connect the customer and the address.
>>
>> First it turned out that the XML printed by vcard-gnccustomer.pl
>> doesn't contain the correct references. Fixed that, but still the
>> file didn't import right. It turned out that the reference setting
>> code in QSF file backend doesn't set the references right. More
>> debugging showed that that code actually never worked right, because
>> after some fixes, it turned out that there is a piece of code that
>> has never been actually executed before, which always segfaults on
>> execution. The bug was simple and got a simple fix. The other is that
>> the function actually increase the list pointer to the end of list on
>> the first execution, so it has a logic error.
>>
>> BUG: ent_ref_cb() has several bugs
>>
>> The bigger issue is that the reference handling code has a number of
>> logic error. I managed to get it to work by hard-coding my GUIDs. The
>> problem is that the references has to be read before all other
>> elements, instead, as currently, with them. This pre-pass is required
>> because when reading the GUID elements the references have be found.
>> I'm thinking of writing a patch.
>>
>> BUG: logic issue with references in QSF backend
>>
>> Additionally the create_reference() function in QOF doesn't work
>> right. The problem is that it always returns newly generated GUID,
>> instead of taking the GUID from the objects given. What's worse is
>> that both GUID pointers in the reference point to the the same memory
>> space, so updating one of the GUIDs, changes the other. Yummy :-)
>>
>> BUG: create_reference() doesn't handle GUIDs right
>>
>> I'll open a different thread about the debug logging issues.
>>
>> So after some fixing, I managed to import successfully this QSF file:
>> <?xml version="1.0" encoding="utf-8"?>
>> <qof-qsf xmlns="http://qof.sourceforge.net/">
>> <book count="1">
>> <book-guid>1288f53dc05562a02a94c58458255d55</book-guid>
>> <object type="gncAddress" count="1">
>> <string type="name">Address Name</string>
>> <string type="phone">555 666</string>
>> <string type="email">blah at yahoo.com</string>
>> <string type="street">Some Street</string>
>> <string type="city">Sofia</string>
>> <string type="locality">My Locality</string>
>> <guid type="guid">1144f53dc05562a02a94c58458255d55</guid>
>> <choice type="owner"
>> name="gncCustomer">1244f53dc05562a02a94c58458255d55</choice>
>> </object>
>> <object type="gncCustomer" count="2">
>> <string type="id">123</string>
>> <string type="name">Customer Name</string>
>> <guid type="guid">1244f53dc05562a02a94c58458255d55</guid>
>> <guid type="addr">1144f53dc05562a02a94c58458255d55</guid>
>> <boolean type="active">true</boolean>
>> </object>
>> </book>
>> </qof-qsf>
>>
>> As a last few words, what to do with the patches. Where do I send
>> them for eventual incorporation into the SVN. Also will "svn diff"
>> result be with the right format for the patches? It seems normal
>> unified diff format.
>>
>> Regards,
>> Georgi
>>
>>
>>
>
>
>
--
*Mirchev Ideas Ltd.*
1111 Sofia, Bulgaria
Golash 18
( + 359 2 ) 870 55 66
manager at mirchevideas.com <mailto:manager at mirchevideas.com>
ICQ: 77517413
Yahoo: mirchevideas
MSN: manager at mirchevideas.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: manager.vcf
Type: text/x-vcard
Size: 550 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060529/96e83eb5/manager.vcf
More information about the gnucash-devel
mailing list