Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EMF-IncQuery » Querying Derived Features
Querying Derived Features [message #1124521] Thu, 03 October 2013 12:17 Go to next message
Eric Lépicier is currently offline Eric Lépicier
Messages: 5
Registered: October 2013
Junior Member
Hi everyone,

I'm beginning with IncQuery 0.7 and facing the query of derived features.
I think I have understood the concept of "well behaving" and I know that the derived features I want to query are not in this case ;-(

So I searched the documentation to make it work and found several web pages :
1/ /incquery.net/incquery/examples/derivedfeatures which explains the declaration of derived features with the org.eclipse.viatra2.emf.incquery.wellbehaving.derived.features
extension point and the @CodeGeneration annotation. Both of them seems deprecated, as well as this page ?
2/ /incquery.net/incquery/new/examples/derivedfeatures which speaks also about the org.eclipse.viatra2.emf.incquery.wellbehaving.derived.features
extension point but tells nothing about any anotation in the query using a derived feature.
3/ /wiki.eclipse.org/EMFIncQuery/UserDocumentation/Query_Based_Features seems to be more up to date, speaking of an org.eclipse.incquery.runtime.base.wellbehaving.derived.features extension point which exists in my dist.

First, assuming my derived features would be correctly implemented, I understand I have to force IncQuery engine to consider them by providing a plugin extending org.eclipse.incquery.runtime.base.wellbehaving.derived.features, with no more code code than the declarative tags <wellbehaving-derived-feature> in the plugin.xml file ? I don't have to write an annotation in my .eiq file to suppress the warning ?

Secondly, as I know that my derived features are not well behaving, which method shall I use to make them better in their implementation : adding a DerivedFeatureHandler as in 1/, a QueryBasedFeatureHandler and accessors as in 2/ and 3/ ?

I tried the examples from /github.com/ujhelyiz/EMF-IncQuery-Examples/tree/master/derived-features-by-queries, but there's many errors, seems to be 0.6 based ?

Anyway, any help to put me on the right way will be greatly appreciated !

Cheers,
Eric

PS : Sorry for the links, beeing a newbie on thie forum, I don't have rights to link outside eclipse.org ...
Re: Querying Derived Features [message #1124644 is a reply to message #1124521] Thu, 03 October 2013 15:06 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan Ujhelyi
Messages: 175
Registered: July 2009
Senior Member
Hi,

first of all, sorry for the documentation issues; we have to find the time and redirect everything to the Eclipse wiki (as far as I know, everything should be migrated by now). About the question: yes, the eclipse wiki link should be up-to-date.

If your derived feature is well-behaving, then yes, you simply have to add the extension. This plug-in also needs to be installed, as of now, IncQuery does not consider extensions defined in the workspace (but otherwise, no extra code is needed).

About your final question: you should not use IncQuery Derived features if you are not allowed to change your EMF implementation code, as it would not work as expected. However, if you only want to use the results in another pattern, then you could simply refer to your derived feature pattern using the 'find' construct, something as follows:

/* This pattern could be annotated with the QueryBasedFeature annotation, but we cannot modify the EMF generated code, so no annotations here */
pattern featureReplacement(srcObject, featureValue) {
... //Constraints here
}

pattern queryPattern(...) {
//Instead of ObjType.FeatureType(a, b); use
find featureReplacement(a, b);
}

But if you want to generate the matcher inside the EMF model, then follow the eclipse wiki links.

I hope, it is clear this way. If not, feel free to ask for clarification.

Cheers,
Zoltán
Re: Querying Derived Features [message #1125127 is a reply to message #1124644] Fri, 04 October 2013 03:19 Go to previous messageGo to next message
Abel Hegedus is currently offline Abel Hegedus
Messages: 62
Registered: July 2009
Member
Hi,

if I understood correctly, you want to use your derived features in EMF-IncQuery in some way. As you found, only well-behaving derived features are allowed by the engine, since otherwise incremental updates are not correctly sent and your query results will be incorrect (see here). An up-to-date example is found here

To declare well-behaving features, you need to use the org.eclipse.incquery.runtime.base.wellbehaving.derived.features extension point. In the extension, you need to give the nsUri, EClass name and feature name to identify features, by omitting the feature name, you declare that all derived features of the EClass are well-behaving and by also omitting the EClass name, you declare that all derived features in all EClasses of the given package are well-behaving. For an example, see here

As you said, your derived features are NOT well-behaving in their current implementation, so you have to make them well-behaving, by one of the following ways:

  • Implement your own well-behaving feature by recomputing when necessary and sending notifications. This is hard and error-prone, so not recommended, unless you have "almost" well-behaving features.
  • Use the DerivedFeatureAdapter (see here) and register the dependencies of the method in it. This is the less intrusive if you only depend on some features and not traverse deeply into the model during calculation, however it will provide lower performance since the recalculation will happen every time a dependency changes.
  • Reimplement your derived feature as a query-based derived feature, this is approach is described here. This can be used, if you can describe your derived feature as a query in EMF-IncQuery. The advantage of this solution over just describing your feature as a query (as Zoltán proposed) is that once you change your derived feature to query-based, it will be transparent to all EMF applications, since they can call the getter and also listen to notifications, without knowing that underneath it is handled by EMF-IncQuery.


What may not be easy to see from the various documentation is the following: if you add the @QueryBaseFeature annotation to a query, the code generation will kick in and it will create both the well-behaving extension and create the getter in the EMF model code. This approach was developed to free developers from manually creating these scaffolding code to get query-based features working.
Re: Querying Derived Features [message #1125537 is a reply to message #1124521] Fri, 04 October 2013 12:21 Go to previous messageGo to next message
Jean-François Voinot is currently offline Jean-François Voinot
Messages: 1
Registered: October 2013
Junior Member
Hi,

I'm working with Eric on this subject.

I will try the second solution (DerivedFeatureAdapter), it seems to be the best one, the less intrusive, and the easy one ... (i'm not an EMF expert Rolling Eyes)
Our goal is to do some requests on the model (we don't really need to detect changes, for now). IncQuery offers more services than we need.

I just found an example to use this adapter:
Thanks to you for your great and complete documentation !

Regards,
Re: Querying Derived Features [message #1127092 is a reply to message #1125537] Sun, 06 October 2013 04:41 Go to previous messageGo to next message
Abel Hegedus is currently offline Abel Hegedus
Messages: 62
Registered: July 2009
Member
Just to clarify, the DerivedAttributeAdapter you found in the EMF Recipes page is actually the original idea that we adopted and extended, as documented in the header of DerivedFeatureAdapter.

We also understand the need for "check-once" type of querying using patterns written in our query language. You could create a request on Bugzilla for collecting some ideas relating to this, if you are interested.

[Updated on: Sun, 06 October 2013 04:43]

Report message to a moderator

Re: Querying Derived Features [message #1128310 is a reply to message #1127092] Mon, 07 October 2013 11:01 Go to previous messageGo to next message
Eric Lépicier is currently offline Eric Lépicier
Messages: 5
Registered: October 2013
Junior Member
Hi,

Thanks Zoltan and Abel for your answers, making it clear for me now.

I had the same idea than Zoltan first suggestion, aka writing a pattern to "code" the derived features and reuse it in queries.
However, I think this method has several disadvantages :
- It is less natural, forcing the use of 'find' instead of the dot notation
- Cascading writings are not possible, and pattern paths are broken in several code parts
- Derived features patterns have to be present in the same query file ? Did I miss somethng about some kind of inclusion or reference to patterns stored in another .eiq file ?
- Every derived features to be used must be expressed, redundantly with the metamodel implementation and thus have to be kept coherent with it.

I'd really like having a well behaving metamodel !
I'm not sure the DerivedFeatureAdapter will work well for complex derived features (computations with many hops, or filtering features).
What's your opinion ?

The third solution seems to be the best, but I can't decide changes on metamodel implementation ...

Cheers,
Eric
Re: Querying Derived Features [message #1128320 is a reply to message #1128310] Mon, 07 October 2013 11:12 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan Ujhelyi
Messages: 175
Registered: July 2009
Senior Member
Hi,

if you can update your metamodels, then making the features well-behaving is indeed the best option to do.

One addition:
- Derived features patterns have to be present in the same query file ? Did I miss somethng about some kind of inclusion or reference to patterns stored in another .eiq file ?
No, they don't have to. Currently, we have some tooling issues that strongly suggest that they are stored in the same project (otherwise, it is possible that you end up with having the same Rete network built twice), but inter-file dependencies work inside a project.

You can either write find org.eclipse.incquery.patternName(parameters), or you could use the 'uses' declaration to import that pattern, similarly as import declarations work in case of Java programs: you simply have to import the fully qualified name of the pattern.

Cheers,
Zoltán
Re: Querying Derived Features [message #1128329 is a reply to message #1128310] Mon, 07 October 2013 11:21 Go to previous messageGo to next message
Istvan Rath is currently offline Istvan Rath
Messages: 52
Registered: July 2009
Member
Hi,

Quote:

However, I think this method has several disadvantages :
- It is less natural, forcing the use of 'find' instead of the dot notation
- Cascading writings are not possible, and pattern paths are broken in several code parts
- Derived features patterns have to be present in the same query file ? Did I miss somethng about some kind of inclusion or reference to patterns stored in another .eiq file ?
- Every derived features to be used must be expressed, redundantly with the metamodel implementation and thus have to be kept coherent with it.

I'd really like having a well behaving metamodel !
I'm not sure the DerivedFeatureAdapter will work well for complex derived features (computations with many hops, or filtering features).
What's your opinion ?


IMHO, the situation is as follows:

- manually writing well-behaving derived features in Java is hard (especially for complex logic), since you have to manage dependencies and stabilize notification loops manually.

- query-based derived features can relieve you of this burden entirely, at the price of having to use our query language, and re-engineering your metamodel (i.e. changing your old implementations to the new ones, as you wrote, maintaining two alternative implementations of the same thing concurrently is an unreasonable overhead).

- in-between these two extremes, you can rely on intermediate solutions (i.e. DerivedFeatureAdapter and our variant), but these solutions also have some (performance) disadvantages and do not scale to complex derivation logic. In my view, this approach is only viable if you would absolutely like to stick with (parts of) your existing code, but it is likely to result in unmaintainable code in the long run.

In an upcoming talk at EclipseCon Europe 2013 (http://www.eclipsecon.org/europe2013/xcore-meets-incquery-how-new-generation-dsls-are-made), I am going to talk about exactly this subject and show how the combination of Xcore and IncQuery can be efficiently deployed to solve this issue. However, this approach would also involve "porting" of your existing DSL to a new infrastructure and leaving old stuff behind.

On more question at the end:

Quote:

- Cascading writings are not possible, and pattern paths are broken in several code parts


Can you elaborate in a bit more detail on what you mean by this? How could the query language be improved?

[Updated on: Mon, 07 October 2013 11:31]

Report message to a moderator

Re: Querying Derived Features [message #1129454 is a reply to message #1128329] Tue, 08 October 2013 12:41 Go to previous messageGo to next message
Eric Lépicier is currently offline Eric Lépicier
Messages: 5
Registered: October 2013
Junior Member
Hi Istvan,

Thanks for your answer, I'm convinced we have to give a try to the QueryBasedFeatures.

To explain my remark:

Quote:


On more question at the end:

Quote:

- Cascading writings are not possible, and pattern paths are broken in several code parts


Can you elaborate in a bit more detail on what you mean by this? How could the query language be improved?



As an example, writing a query like:
pattern sample(a:A, d:D) {
   A.feature1.feature2.feature3(a, d);
}

with a derived feature pattern for feature2 would lead to:
pattern sample(a:A, d:D) {
   A.feature1(a, b);
   find feature2pattern(b,c);
   C.feature3(c, d);
}
pattern feature2pattern(b:B, c:C) { ... }

and doesn't show the pattern path as clearly.

An improvement to the language could be to consider binary patterns (those which links two concepts) in a similar way than features in dot cascaded patterns. In my example, it would mean being able to write the first compact form with feature2pattern being a subpattern, like this:
pattern sample(a:A, d:D) {
   A.feature1.feature2pattern.feature3(a, d);
}
pattern feature2pattern(b:B, c:C) { ... }


Then, naming the sub pattern like the feature would give:
pattern sample(a:A, d:D) {
   A.feature1.feature2.feature3(a, d);
}
pattern feature2(b:B, c:C) { ... }


Just need to manage priorities between features and subpatterns, raise warnings on ambiguities ...

Cheers,
Eric

PS: Thanks Zoltan for the cross-file patterns tip !
Re: Querying Derived Features [message #1130112 is a reply to message #1128320] Wed, 09 October 2013 04:35 Go to previous messageGo to next message
Eric Lépicier is currently offline Eric Lépicier
Messages: 5
Registered: October 2013
Junior Member
Zoltan Ujhelyi wrote on Mon, 07 October 2013 17:12
Hi,

if you can update your metamodels, then making the features well-behaving is indeed the best option to do.

One addition:
- Derived features patterns have to be present in the same query file ? Did I miss somethng about some kind of inclusion or reference to patterns stored in another .eiq file ?
No, they don't have to. Currently, we have some tooling issues that strongly suggest that they are stored in the same project (otherwise, it is possible that you end up with having the same Rete network built twice), but inter-file dependencies work inside a project.

You can either write find org.eclipse.incquery.patternName(parameters), or you could use the 'uses' declaration to import that pattern, similarly as import declarations work in case of Java programs: you simply have to import the fully qualified name of the pattern.

Cheers,
Zoltán



Hi Zoltán,

I got it working with the fully qualified name pattern reference.
By the way, when patterns are in different files, but in the same package, then it works automatically. It's nice and simple, but I didn't discover this by myself !

The "uses" clause still gives me a "Couldn't resolve reference to JvmDeclaredType 'my.pattern.patternName'" error located on the uses line.

I tried double quotes, semicolon at the end of the line ... without success ...
What's the exact syntax of the uses clause ?

Cheers,
Eric
Re: Querying Derived Features [message #1130123 is a reply to message #1130112] Wed, 09 October 2013 04:45 Go to previous message
Zoltan Ujhelyi is currently offline Zoltan Ujhelyi
Messages: 175
Registered: July 2009
Senior Member
Hi,

I have checked it now, and it is for some reason not working as expected, I have opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=418991 for this.

Currently, you can do a package import: «uses org.eclipse.incquery.*» but that would give you a warning, or you have to work with fqn references.

We will take a look at this issue.

Cheers,
Zoltán
Previous Topic:Parameterized queries
Next Topic:How to prevent traversal of objects
Goto Forum:
  


Current Time: Mon Apr 21 11:51:52 EDT 2014

Powered by FUDForum. Page generated in 0.02730 seconds