Problem with QOF_TYPE_COLLECT

[Neil Williams]

>> Tracking down the first message, I started where the due bills 
>> dialog sets up a search query for invoices, one term of which is 
>> the owner of the invoice, set here.
>> 
>> param_list = gnc_search_param_prepend (param_list, _("Company"), 
>> NULL, type, INVOICE_OWNER, OWNER_NAME, NULL)
>> 
>> and fails miserably.  I am able to find where all the other core 
>> qof types are registered with this code in qofquerycore.c, but I 
>> can't find anywhere where the collection type is registered.

The collection is a "secondary" collection, not the same as the main
ones in the book and can contain entity/ies of a different type to the
parent object - naturally all entities in any one collection must be of
the same type. Additionally, a QOF_TYPE_COLLECT can hold entities of ANY
registered type, the object defining the collect type determines which
entity types it will accept and which it can ignore at runtime. So
GncInvoice handles a collect type holding GncCustomer, or GncJob, or
GncEmployee entities (GncInvoice only uses the first one in the
collection and GncOwner is used to determine the acceptable types) -
the precise entity type determined when the data file is read in.

I've written a starter for the QOF_TYPE_COLLECT query predicates, I'm
just checking that I've got it right:

The comparison routine uses qof_collection_compare.
The equality function does the same.
The predicate uses a list of GUID's.
Matches are done according to the GUID.

Will that preclude the existing searches (e.g. for Company_Name) - is
there a test routine?

So I get:
QofQueryPredData *
qof_query_collect_predicate (QofGuidMatch options, QofCollection *coll)

    { QOF_TYPE_COLLECT, collect_match_predicate, collect_compare_func,
      collect_copy_predicate, collect_free_pdata, NULL,
      collect_predicate_equal },

collect_match_predicate is largely lifted from guid_match_predicate -
qof_query_collect_predicate lifts the GUID's of each entity in the
QofCollection into a GList in query_coll_def, (*query_coll_t).

I'm not sure about the ToString because I don't see how that can be
enabled for a collection of entities - it isn't enabled for GUID's
either so maybe that's a red herring and completing the registration of
QOF_TYPE_COLLECT with the query engine will be sufficient.

Before I commit, I thought I'd best check if I'm way off (again).

Is this the correct way to handle a collection in a query?

(and I'm growing to hate Thunderbird's preference for full screen
message composing! There's a bug in kmail related to yet more string
problems, this time QString.)

Will this require any changes elsewhere?

-- 

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/a7142415/signature.bin