> Hi Esteban,
>
> The idea of a QCQuery is to search in a dataset, arbitrarily how it is
> organised. It does so by recursively visiting the magritte description of
> the objects, and has protection against loops. For instance:
> if you have parties in your model, and each party has addresses
> (telephone, email, post): you can pass your model to your query and it
> searches through all parties and addresses to find things that match.
>
> The query itself is build up in 3 different parts:
>
> The select. This can be a simple string (the string value of any field
> matches: '06410', a conditional string ('name' = *'die'*), or a complex
> query that is an and/or of possible selects. The select could easily be
> extended with extra things, with the only requirement that they implement
> the "#matches:" (or "matches:description: if more control is needed).
>
> The target and search path. That together determine the part of the model
> that is searched.
>
> The results description. The result set itself generates a magritte
> description. When nothing specified in the results description it returns
> the magritte description of the common class of the results. You can add an
> extra filter here, that you only want results of a certain type, or add
> columns to give additional calculated fields in the results.
>
> My query does not sort and/or group and has no translation into SQL. So I
> have the feeling there is a mismatch here. As my need was to search the
> objects that are loaded in the image, and allow the user to search through
> them. So it does have a string representation the is human readable.
>
> Regards,
> Diego
>
>
>> 1. What I have today is a result set (a collection of my domain objects)
>> which can be managed independently of what objects I have (it is,
>> different
>> domain classes). To solve this I use Magritte Descriptions to define my
>> metamodel.
>>
>> 2. What I need is a way to add "behavior" to such data set, like filtering
>> (elements whitin certain group, state, etc.), value
>> grouping/aggregation...,
>> sorting, custom columns, etc.
>>
>> It is... basic result set management plus pivot table behavior...
>>
>> 3. What I would like is to have the query described somehow, in order to
>> translate it to a GLORP query to avoid loading a whole table to fetch only
>> a
>> few rows. These days I can do that, but I want to avoid it.
>>
>> We did this in my previous job on top of our own metamodel system (very
>> alike to Magritte), and I'm willing to code it again on top of Magritte if
>> needed. But as always... we need to deliver, and the time is scarce...
>>
>> Regards!
>>
>>
>> --
>> View this message in context:
>>
http://forum.world.st/Deep-QCMagritte-tutorial-tp4744612p4744695.html>> Sent from the Magritte, Pier and Related Tools mailing list archive at
>> Nabble.com.
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>>
https://www.iam.unibe.ch/mailman/listinfo/smallwiki>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
>
https://www.iam.unibe.ch/mailman/listinfo/smallwiki>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
>
http://forum.world.st/Deep-QCMagritte-tutorial-tp4744612p4744943.html> To start a new topic under Magritte, Pier and Related Tools, email
>
[hidden email]
> To unsubscribe from Magritte, Pier and Related Tools, click here.
> NAML