Home » Archived » EMF-IncQuery » Parameterized queries
|Parameterized queries [message #1129590]
||Tue, 08 October 2013 20:04
| Eric Lépicier
Registered: October 2013
I would like to build reusable queries, which could be evaluated in different contexts without having to modify them.
I read about the filter functionality of the Query Explorer, documented in //incquery.net/incquery/documentation/ui#Parameterized_queries
I also found a topic in this forum which discuss quite the same need : "Substring search in atributes" here http://www.eclipse.org/forums/index.php/t/477146/
My need would to be able to add symbolic values in check computation.
For example, with the school model, I'd like to:
- Write a query including a check on Course.weight being lower than a threshold, set by the user before query evaluation
- Write a query like teachersOfSchool, but focused on a particular school which might have been selected in another tool, making the query contextual like the 'self' in OCL.
The first one is quite the same need than in the "Substring search in atributes" topic, a kind of externalization of constants used in checks.
The second one is well resolved with filters, but I was asking myself about performance. Isn't it more efficient to reduce the number of combinations as soon as possible ? With filters, the whole graph result is computed and then it may be drastically pruned, having unnecessary computations been done ?
I can imagine some solutions:
- augment the filtering ability (now equality vs constants or objects) with complete expressions (relational operators, ...), implementing a kind of Having SQL clause. That's something we could implement ourselves.
- extend pattern grammar, by adding "input parameters" to the pattern prototype. Seems really more complicated ... !
- use model interconnection : for the second case, one could query both the content model and a selection model. I saw but did not experiment //incquery.net/incquery/new/examples/query-driven-soft-links
Any ideas, answers about cost of post-processed queries ?
|Re: Parameterized queries [message #1129607 is a reply to message #1129590]
||Tue, 08 October 2013 20:26
| Zoltan Ujhelyi
Registered: July 2015
what you want to achieve, is at this point not really feasible inside the IncQuery runtime where the basic idea is to store all possible solutions.
Simply extending the grammar would not help you, as this kind of filtering also needs to be supported in the Rete algorithm - this would require a non-trivial (but possible) extension.
What is possible to do now:
1. If you have a constant filtering expression you could code it as a check expressions, as you have already found. Of course, this is not really versatile.
2. EVM (http://wiki.eclipse.org/EMFIncQuery/DeveloperDocumentation/EventDrivenVM), a virtual machine has such EventFilters implemented you want, but they all operate on the result sets of matches - in other words, they are filtered after the pattern matching phase has finished. Unless you need all the power of EVM, I am not really suggesting to take this approach.
3. When you use the IncQuery Matcher API, you could write your filters in Java as the first step after getting the results.
About your cases:
1. The treshold can be implemented using a check expression that uses a query parameter. When you call the query from the Java API, it can return the results effectively. If you update the treshold, the index already stores the result, so this can be updated fast.
2. Focusing on a single school is not really supported. You could initialize an IncQueryEngine on either an EMF ResourceSet, an EMF Resource or the objects available through containment references from a selected model elements. But if you only need to be able to select results from different schools, then your best solution is to set the selected school as a match parameter, and get your filtered results using the Matcher API.
I hope, I was clear enough. If not, feel free to ask for clarification.
|Re: Parameterized queries [message #1129612 is a reply to message #1129590]
||Tue, 08 October 2013 20:31
| Abel Hegedus
Registered: September 2015
for the first case, you are right, it is similar to the "substring search", the incremental query engine is best used for keeping an always up to date list of matches that are hard to find in order to support the rest of the computation that is nat related to model traversal. By querying all course weights, you can quickly "filter" the ones that are lower then a threshold.
The second case is perfectly suited for the API of EMF-IncQuery, the generated matchers can be called with defining one or even all parameters of the match. Of course, you can always get all matches of a pattern as well.
In your example, you would have a teachersOfSchool(school, teacher) pattern, so the generated TeachersOfSchoolMatcher has a getAllMatches(School pSchool, Teacher pTeacher) method. You can:
1. call getAllMatches(null, null) to find all teacher-school pairs
2. call getAllMatches(s, null) to find all teachers of school "s".
3. call getAllMatches(null, t) to find all schools of teacher "t".
As for "redusing the number of combinations as soon as possible": the Rete network implementation of the incremental query engine will have to cache all partail matches anyway, so it would be hard to gain a significant advantage.
Finally, consider the lambda expressions in Xtend which complement our API really nicely. E.g.
studentsInCoursesOfTeacherMatcher.countMatches(pTeacher,null) > 30
Which will find teacher-school pairs, where the teacher has at least 30 students in the different courses he teaches.
(Update: as Zoltán pointed out in the next message, my original code was incorrect, sorry)
[Updated on: Wed, 09 October 2013 15:19] by Moderator
Report message to a moderator
Current Time: Sat Apr 30 18:57:15 GMT 2016
Powered by FUDForum
. Page generated in 0.14303 seconds