Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EMF-IncQuery » Not representable well-behaving feature
Not representable well-behaving feature [message #1244123] Tue, 11 February 2014 18:39 Go to next message
Emre T is currently offline Emre T
Messages: 119
Registered: April 2013
Senior Member
Hello

in the definition of my @QueryBasedFeature patterns, I am getting the following warning for derived references of my own model elements to other elements of an other imported Ecore package:

The derived/volatile feature referenceConstruct of class CreateInterface used in the path expression is not representable in EMF-IncQuery. For details, consult the documentation on well-behaving features.

I have double-checked, that these references are derived (true), volatile (true), transient (true) and non-changeable (false), so well-behaving. I couldn't actually got my queries run, because of some other errors, but I wanted to know, whether you are familiar with these warnings are?

Thanks a lot!

Emre

P.S: The references are also non-containment references from my model classes to other imported model classes and have different cardinailities, if it is any important.
Re: Not representable well-behaving feature [message #1244350 is a reply to message #1244123] Wed, 12 February 2014 02:47 Go to previous messageGo to next message
Gabor Bergmann is currently offline Gabor Bergmann
Messages: 15
Registered: July 2009
Junior Member
I think you misunderstand what we mean by well-behaving derived feature.
Please take a look at: https://wiki.eclipse.org/EMFIncQuery/UserDocumentation/Query_Based_Features#Well-behaving_structural_features

The key is that whenever the value of the derived feature changes, it must be able to emit proper EMF notifications - otherwise live queries / incremental evaluation would not be possible. For example, something like java.lang.System.currentTimeMillis(), if it were an EMF structural feature, would be transient, volatile, derived, and non-changeable. Yet it would not be well-behaving, as its return value could (and would) change between invocations, without providing notifications whenever a millisecond has passed.
Re: Not representable well-behaving feature [message #1245212 is a reply to message #1244350] Thu, 13 February 2014 08:17 Go to previous messageGo to next message
Emre T is currently offline Emre T
Messages: 119
Registered: April 2013
Senior Member
Hello Gabor,

it seems so, that I am really missing something about the well-behaving derived references. I thought that declaring those references or attributes derived, volatile, transient and non-changeable in practice would enough that they well-behave?

Though the warnings are somehow gone, when I open my IncQuery project in an Eclipse runtime. Do you have any further ideas why?

Thanks!

Emre
Re: Not representable well-behaving feature [message #1245225 is a reply to message #1245212] Thu, 13 February 2014 08:38 Go to previous message
Abel Hegedus is currently offline Abel Hegedus
Messages: 88
Registered: July 2009
Member
Actually, "derived, volatile, transient and non-changeable" means that they are _not well-behaving_ since by default, EMF will not provide change notifications for such features.

If you use derived features (non query-based) and manually code them to send notifications (e.g. ADD, SET, REMOVE), then your feature is _made_ well-behaving, and you can tell EMF-IncQuery this fact by registering it through an extension.

However, if you use _query-based_ derived features (by defining a pattern and adding the @QueryBasedFeature annotation), those will be well-behaving by definition, since the query-based feature runtime plugin will make sure that correct notifications are sent. Therefore, the well-behaving extension is automatically generated along with the modification of the getter code.

The extension is added to the plugin.xml of the EMF-IncQuery project where you defined the pattern. If you include this project in the runtime Eclipse, then those generated extensions will be parsed and the EMF-IncQuery editor will also know that the feature is well-behaving.
Previous Topic:Is it possible to use incquery in Standalone EMF?
Next Topic:Queries for derived features with constrains
Goto Forum:
  


Current Time: Thu Jul 24 00:22:20 EDT 2014

Powered by FUDForum. Page generated in 0.02122 seconds