QSF Import of gncCustomer and gncInvoice

[Chris Shoemaker]

On Thu, Jun 01, 2006 at 05:04:21AM +0300, Georgi Mirchev wrote:
> 
> Derek Atkins wrote:
> 
> >Georgi Mirchev <manager at mirchevideas.com> writes:
> >
> > 
> >
> >>>Yes and no..  The idea is that QofChoice is a template type..  So
> >>>a GNC_ID_OWNER would be QofChoice<Customer,Vendor,Employee,Job>.  You
> >>>really can't say that it returns a QOF_TYPE_CHOICE because you need to
> >>>know what QofChoice template instance is returned.
> >>>     
> >>>
> >>Actually it is just a declaration of the param type. I do understand 
> >>that the getter doesn't return a QOF_TYPE_CHOICE, nor the setter get a 
> >>QOF_TYPE_CHOICE object. They get/set the real entities from the "allowed 
> >>choice" types.
> >>   
> >>
> >
> >Yes, I realize that, but QofChoice<type1, type2, type3> is effectively
> >a different parameter type than QofChoice<typeA, typeB, typeC>.  So
> >the parameter type should reflect that difference.
> >
> > 
> >
> 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'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.
> 
> 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 the existing API for cloning objects is ill-defined.  If the
purpose of cloning is to copy to another book, then the cloning
functions should be passed the target book.

In general, you should be aware that you're talking about areas of
GnuCash that are only half-baked.  There are probably non-trivial API
changes required to eventually support book merging.

Happy hacking!

-chris