QSF Import of gncCustomer and gncInvoice

[Georgi Mirchev]

I just did. Eight to be exact.
I think that only the patch for the book merge contains some 
workarounds. Also the params that I have added might not be what you had 
in mind.
The gncAddress one is a very good candidate to make it into 2.0.

Derek Atkins wrote:

>Please definitely send in the bug fixes.
>
>As for the new functionality, I think that attaching the patch(es)
>to a bug report (or set of reports) is the right approach.
>
>Personally, I'd rather see something get done "right", because
>at this point it's NOT going into 2.0 so you certainly have a few
>months to get the work done.   ;)
>
>And yes, the code DEFINITELY has a lot of issues...  :(
>
>-derek
>
>Georgi Mirchev <manager at mirchevideas.com> writes:
>
>  
>
>>I do understand your point of view, but my idea is to get results out of 
>>the door. Doing everything right will be a lot of work, and I'm not 
>>prepared to do it all. At least not now.
>>The current code has a lot of things implemented, and with several bug 
>>fixes and with 50-100 additional lines of code I achieved the following:
>>1. import of gncCustomer, gncAddress, gncInvoice, gncEntry and Account
>>2. referencing between the the imported objects so that all of them are 
>>connected - i.e. the addresses belong to customers, the entries belong 
>>to invoices, the owner of the invoice is a customer and each entry 
>>references an account
>>The referencing between imported and target book is not complete, so all 
>>of these have to be imported in one file. But it WORKS.
>>
>>I'm preparing patches now, in case someone finds the code useful. If you 
>>choose not to import all patches, you can import only the bug fixes and 
>>the correct code, and leave the code that is some kind of hack out. Thus 
>>it could be at least partially integrated into gnucash.
>>
>>The code really has a lot of issues, and is far from ready, so this 
>>really is a distraction for 2.0. Thus I'll submit some entries in the 
>>bugzilla with the patches attached, so that they can be handled after 
>>2.0 is out of the door.
>>
>>Derek Atkins wrote:
>>
>>    
>>
>>>Georgi Mirchev <manager at mirchevideas.com> writes:
>>>
>>>
>>>
>>>      
>>>
>>>>It turned out that I just can't use the same parameter for the
>>>>invoices. The "owner" param returns gncOwner object, and is used by
>>>>the rest of GnuCash, so nothing can be changed here.
>>>>Instead I added "owner-qof" that is of type QOF_TYPE_CHOICE, and
>>>>works with entities. It works fine with customers, and will work
>>>>fine with the other 3 objects that can be owners of an invoice. The
>>>>import of customers/addresses works fine now.
>>>>
>>>>
>>>>        
>>>>
>>>I still don't think that's the right answer...  I have no objection to
>>>changing the definition of a GncOwner (although you DEFINITELY need to
>>>be careful about how it's done, because if done "incorrectly" it will
>>>take a LOT of effort to change the code everywhere where it assumes it
>>>knows how a GncOwner is implemented).
>>>
>>>
>>>
>>>      
>>>
>>>>I'm working on the collections now, so that I can import the
>>>>invoice entries. In order to get any entries in, I had to add a
>>>>kludge. The QOF iterates over all parameters of the imported
>>>>object, calling their getters and trying to determine the
>>>>time. Guess what happens when the getter doesn't actually return an
>>>>entity, like in the case of parameter that is of type gncOwner. So
>>>>the QOF book merger code now checks specifically for
>>>>"gncOwner". Kludge, but works. Unless we add additional param flag
>>>>"has QofInstance", so that it is compatible with QOF, or  we add
>>>>dummy QofInstance to gncOwner, I can't see how to resolve that.
>>>>
>>>>
>>>>        
>>>>
>>>... and this is DEFINITELY not the right answer.  We shouldn't
>>>special-case anything inside QOF.
>>>
>>>
>>>
>>>      
>>>
>>>>There is an issue that seems to be a little more complex. During
>>>>the merge of two books the entries from the first are "copied" into
>>>>the second, then the first book and it's entries are destroyed. The
>>>>problem is that the "copy" often is just pointer copy. The reason
>>>>is that although we have clone functions in the gnc objects, the
>>>>QofObject doesn't specify a 'clone' callback, so QOF cannot clone
>>>>any objects. I think this needs to be added, so that QOF can safely
>>>>clone an object whenever needed.
>>>>What do you think?
>>>>
>>>>
>>>>        
>>>>
>>>I think, as Chris said, that these APIs are only half baked and really
>>>require a lot of thought and effort to make work correctly.  I would
>>>recommend you sit back and come up with a reasonable design before you
>>>jump head-first into coding it up.  come up with a page or two
>>>describing how you think it should work.  Be detailed, but not
>>>loquatious.
>>>
>>>Once you have a design we can talk about the merits, work that out,
>>>and then you're welcome to go full-bore into it.
>>>
>>>Keep in mind that we're really trying to get 2.0 out the door, so
>>>don't expect many cycles on something like this which really is a 2.0
>>>distraction.
>>>
>>>-derek
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>gnucash-devel mailing list
>>gnucash-devel at gnucash.org
>>https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>    
>>
>
>  
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: manager.vcf
Type: text/x-vcard
Size: 527 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060602/89b2fa3e/manager.vcf