QSF Import of gncCustomer and gncInvoice

[Derek Atkins]

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

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