Problem with QOF_TYPE_COLLECT

[Derek Atkins]

See, this is why I've said all along that an Owner is _NOT_ a collection.. It's
a CHOICE.  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...

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.

Unfortunately your workarounds are not sufficient.  It will break a lot of
existing queries in a number of places.

-derek

Quoting Neil Williams <linux at codehelp.co.uk>:

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


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