QSF Import of gncCustomer and gncInvoice

[Derek Atkins]

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