Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "VIATRA/Query/DeveloperDocumentation/LocalSearch/ConstraintApplicationCondition"
m |
|||
| Line 4: | Line 4: | ||
| − | = Unknown type system, no base index, no match index = | + | === Unknown type system, no base index, no match index === |
This could be the general case for constraint application. Under such circumstances, allowed operation adornments are the following: | This could be the general case for constraint application. Under such circumstances, allowed operation adornments are the following: | ||
| Line 13: | Line 13: | ||
| − | = Known type system, no base index, no match index = | + | === Known type system, no base index, no match index === |
The type system is known, this means that subtype-supertype relations as well as model environment specific properties are known. This information can maily be used for two purposes: | The type system is known, this means that subtype-supertype relations as well as model environment specific properties are known. This information can maily be used for two purposes: | ||
| Line 20: | Line 20: | ||
| − | = Unknown type system with incremental indexing = | + | === Unknown type system with incremental indexing === |
This case index is available for certain type of model elements and/or matches for certain patterns. | This case index is available for certain type of model elements and/or matches for certain patterns. | ||
| Line 28: | Line 28: | ||
* In case of positive pattern calls during local search-based pattern matching, the results of a previously initialized RETE pattern matcher can be used for a very low cost, if such matcher is available. (NOTE: however, if no such matcher exists, it is a nontrivial problem to determine whether it is worth initializing a RETE matcher for a sub-pattern or not.) | * In case of positive pattern calls during local search-based pattern matching, the results of a previously initialized RETE pattern matcher can be used for a very low cost, if such matcher is available. (NOTE: however, if no such matcher exists, it is a nontrivial problem to determine whether it is worth initializing a RETE matcher for a sub-pattern or not.) | ||
| − | = Known type system, existing index = | + | === Known type system, existing index === |
This is scenario could be the optimal case, for the combination of the above mentioned advantages is available, and the most application conditions are allowed. This case the planner can choose from a great variety of constraints with different operation adornments. | This is scenario could be the optimal case, for the combination of the above mentioned advantages is available, and the most application conditions are allowed. This case the planner can choose from a great variety of constraints with different operation adornments. | ||
Revision as of 11:03, 15 June 2015
Contents
Constraint application scenarios
The adornment of a search operation derived from a constraint is considered as the application condition of the operation. Based on the type system of the modeling environment and the state of the available indexes (both base and match index) different application conditions can be considered. This page is intended to give an overview of such scenarios under different circumstances.
Unknown type system, no base index, no match index
This could be the general case for constraint application. Under such circumstances, allowed operation adornments are the following:
- Unary constraints: F, B
- Binary constraints: BF, BB
- Ternary constraints (ordered collection, middle variable is the index): BFF, BBF, BFB, BBB
- n-ary: in this case we have no additional information about the constraint, preferred variable binding is BB...B
Known type system, no base index, no match index
The type system is known, this means that subtype-supertype relations as well as model environment specific properties are known. This information can maily be used for two purposes:
- Infer the most specific type of a variable and then only consider model object of that type
- Obtain the inverse of a binary relation. In case of EMF, this means obtaining the eOpposite feature. Using this feature, for binary relations the adornment FB can also be an application condition, for it can be a BF condition for its inverse.
Unknown type system with incremental indexing
This case index is available for certain type of model elements and/or matches for certain patterns.
- Using the index, elements of a given type can easily be enumerated
- With the index, the inverse navigation is also possible, so that for binary constraints a FB is also a valid application condition
- The index can be applied for edges, which gives an opportunity for binary constraints with FF application condition
- In case of positive pattern calls during local search-based pattern matching, the results of a previously initialized RETE pattern matcher can be used for a very low cost, if such matcher is available. (NOTE: however, if no such matcher exists, it is a nontrivial problem to determine whether it is worth initializing a RETE matcher for a sub-pattern or not.)
Known type system, existing index
This is scenario could be the optimal case, for the combination of the above mentioned advantages is available, and the most application conditions are allowed. This case the planner can choose from a great variety of constraints with different operation adornments.