Problem with QOF_TYPE_COLLECT

[Neil Williams]

Derek Atkins wrote:
> See, this is why I've said all along that an Owner is _NOT_ a 
> collection.. It's a CHOICE.

OK, I was hoping that as it is a choice between one entity from a
collection of types (and that it merely happened in this case to be a
single entity at a time) that it could be handled in the same way as a
collection (like Entries) of the same type. The root of the problem is
one-to-many linkage. One parameter containing a predictable collection
of entity references.

I used QofCollection because of the tight control of 1 type per
collection. It makes it easy to handle multiple entities. A GList of
entities of more than one type is much more difficult to handle. Even if
each instance only contains one entity, the fact that the one parameter
can access entities of more than one type makes it very difficult to
handle generically.

The current backend knows about these things in advance, QOF cannot.

> It is always One and ONLY ONE object, but it's a single object of a 
> bunch of different types.  An owner can be a Job, a Customer, a 
> Vendor, or an Employee...  But there is still One and ONLY ONE 
> object...

Agreed.

The collection was designed with a view to general QOF objects, not
exclusively for GncOwner. I need a better solution that is still
generic. I'm wondering (out loud) about KVP.

> So...  IMHO the "collection" is the wrong abstraction for an owner. 
> I've just not been able to say this in a way that I think makes it 
> clear to you.

I see the problem and I'm going to have to revert the change.

I still need one parameter capable of retrieving multiple entity
references in two examples:

1. The Owner parameter that is one entity with one of 4 different entity
types.
2. The entries in the invoice that can be many instances of 1 entity type.

I first tried this by making GncOwner and GncEntry available for export
directly. Even with GncEntry available, I still need to find the entries
from the invoice via QOF parameters. I may go for a temporary KVP frame.
(Created by QOF within the object, used to build the list of entities to
find and then discarded). These would then be retrieved using (yet more)
dedicated parameters and functions, removing the need for a param_setfcn
on the Owner parameter so that QOF can query it but not export or merge it.

One (poor) alternative is to hard-code into the export routines that a
GncInvoice always has a GncOwner, the export routine would have to
obtain and look up the owner and add that GncCustomer (etc.) entity to
the export explicitly. The exported invoice would then contain a GUID
reference to the GncCustomer, or whichever is used. However, if the
invoice object changes, hardcoded exports would need to be
re-written.

IMHO, a temporary KvpFrame is a better option, QOF could look up the
reference and use the value of that key to know the type. It's not as
robust as QofCollection but it could be OK.

I wanted to allow QOF to follow the references between objects and
enable some form of recursion so that exporting an invoice would
automatically bring along each referenced entity so that the export was
a more usable item. Just exporting an invoice with only the GUID of the
entries, the owner and the bill terms seemed a little underwhelming.

KVP could be used to indicate that this invoice entity needs to be
exported with that GncCustomer entity, etc.

For now, I may keep QOF_TYPE_COLLECT in QOF itself but remove it's
expression in the GnuCash objects. What GnuCash doesn't know can't hurt
it. (!!). If it turns out that it can be done slightly differently, it
can always be renamed to better express the concept. I'll then hard-code
the exports so that the UI code recurses through the objects that it
already understands and copies the relevant entities into the export
QofBook or use temporary KVP frames.

Comments?

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050706/9825fa35/signature.bin