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