Home » Archived » EMF-IncQuery » Inherited derived references
| Inherited derived references [message #1272308] |
Mon, 17 March 2014 15:53  |
 Emre T
Messages: 119
Registered: April 2013 |
Senior Member |
|
|
Hello again, I wanted to open a new thread regarding the subject, even though we have actually discussed some relevant things on an another thread [*]. But I believe the following issue deserves its own one. I will try to explain the situation as informative as possible. There are two uploaded simple model parts related to the query definition.
For the first upload as above (the old derived model), my pattern definition was working correctly and without any warnings, except some performance issues. The pattern definition was something like the following:
@QueryBasedFeature(feature = "derivedReference")
pattern derivedPattern(This: Sub, Target: Target) {
// Get the ID from Super1 and compare it to some features of Target,
// if true set the derived reference to Target
}
But since the model had to be changed for separation reasons, I added a second super class, which the first Sub class inherits beside the Super1. So the new model looks like this:
As you can see, the derived reference is now between the Super2 and Target, not with Sub, which has the ID feature from Super1. First I thought that this shouldn't be so hard to implement, since the Sub is also a Super2 and therefore has the same derived reference and the getDerivedReference() method which should be implemented. First I have implemented the following query.
//Warning: Inconsistent parameter type definition, should be ClassReferencingDecision based on the pattern definition
private pattern getSub(super2: Super2) {
Sub(super2)
}
@QueryBasedFeature(feature = "derivedReference")
pattern derivedPattern(This: Super2, Target: Target) {
find getSub(This);
// Get the ID from Super1 and compare it to some features of Target,
// if true set the derived reference to Target
}
But it failed and I think because it is not possible to traverse inheritance from super to sub class. On the derived pattern, there were one warning "Inconsistent parameter type definition, should be Sub based on the pattern definition" on the pattern declaration and followed by the error "Cannot find feature derivedReference of EClass Sub." on the @QueryBasedFeature annotation. I think that this has something to do with the private pattern getSub(Super2), because the moment I comment it out, both warning and error are gone. As expected an error saying that the parameter "This" isn't used in the pattern body surfaces. But the derived reference "derivedReference" between Super2 and Target can be found again.
Then instead of using the above helper query, I defined the Sub as the first parameter of the pattern definition, since it has already inherited the derived reference from Super2:
@QueryBasedFeature(feature = "derivedReference")
pattern derivedPattern(This: Sub, Target: Target) {
// Get the ID from Super1 and compare it to some features of Target,
// if true set the derived reference to Target
}
But again, the derived reference couldn't be found between the Sub and Target with the following error "Cannot find feature derivedReference of EClass Sub.". Even though the feature is inherited from the Super2.
What comes to mind is that the derived features can only be implemented in case if they are only and only the main feature of the super class and not inherited by the sub classes. Or am I missing something?
I am kind of stuck with this issue, which is a very important step for my project, since the first model and relating queries were working correctly with all the desired functions including OCL checks etc.
I would be very glad if you could help me with the issues. Thanks a lot and sorry for the long thread.
Best regards,
Emre
[*] http://www.eclipse.org/forums/index.php/t/672451/
[Updated on: Mon, 17 March 2014 16:03] Report message to a moderator |
|
|
| Re: Inherited derived references [message #1272316 is a reply to message #1272308] |
Mon, 17 March 2014 16:16  |
Abel Hegedus
Messages: 197
Registered: September 2015 |
Senior Member |
|
|
Hi Emre,
the generator of the @QueryBasedFeature always searches for the feature in the EClass determined by the source parameter. In your case, since the feature is in Super2, the pattern header must look like this:
@QueryBasedFeature(feature = "derivedReference")
pattern myPattern(src : Super2, trg : Target){
// query constraints
}
Then, for Sub typed objects, you want to use the ID feature in Super1, therefore the internal should look like this:
@QueryBasedFeature(feature = "derivedReference")
pattern myPattern(src : Super2, trg : Target){
Sub.ID(src, id);
Target.srcID(trg, id); // assuming the same ID is stored in some attribute
}
This will most definitely give you a warning for "Ambigious type [Sub, Super2], Super2 is used", but otherwise should work correctly and generate the code without issues. If this is not the case, then it is probably a bug in the type inference (we know of some strange corner cases already, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=428018, https://bugs.eclipse.org/bugs/show_bug.cgi?id=419114 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=410823)
|
|
| | | | | |
| Re: Inherited derived references [message #1278027 is a reply to message #1277764] |
Wed, 26 March 2014 20:15 |
Abel Hegedus
Messages: 197
Registered: September 2015 |
Senior Member |
|
|
Sorry, I had not yet time to recreate the setup and example that you used to reproduce your issue.
However, if the problem exists without query-based feature annotations, then it is a bug and you should open a bugzilla issue about it.
So, please try the following pattern:
pattern myPattern(src : Super2, trg : Target){
Sub.ID(src, id);
Target.srcID(trg, id); // assuming the same ID is stored in some attribute
}
1. Do not change the pattern header, especially the "src : Super2" part.
2. List the errors/warnings on the pattern.
3. If MyPatternMatch class was generated, tell me what the type of pSrc field is.
By design, the type should be Super2 and that would be the class where the QueryBasedFeature generator would search for the feature. However, the error message you gave before looks like it gets Sub as the type. Which is a bug _IF_ your pattern header is "src : Super2".
|
|
|
| Re: Inherited derived references [message #1283544 is a reply to message #1278027] |
Thu, 03 April 2014 14:41 |
Emre T
Messages: 119
Registered: April 2013 |
Senior Member |
|
|
Hello Abel,
sorry too, that I wasn't able to try your workaround sooner. But now I had the chance to try it out. The result is as follows.
For the 1. question, as you pointed out, I especially let the the pattern definition be as for the second case and with the parameter "src: Super2":
pattern myPattern(src: Super2, trg: Target) {
find getSubOverSuper2(src);
find getIDForSubSub(src, ID);
... // some further patterns to get the corresponding future from the target
check ( // whether two ids are the same );
Target.someReference.someFeature(trg, ID); // Dont mind this part, just tried to simplify it a litte
}
As you can see there are two distinct patterns, but their function is no more than what you expect to do. They look like this:
// Already here I get the warning of inconsistency
// [i]Inconsistent parameter type definition, should be Sub based on the pattern definition[/i]
private pattern getSubOverSuper2(Super2: Super2) {
Sub(Super2);
}
private pattern getIDForSubSub(Sub: Sub, ID: EString) {
SubSub.ID(Sub, ID);
check ( // some further constraints on ID);
}
For the second question, when I removed the @QuertyBasedFeature annotation, the error about not being able to find the derived reference was gone. The only two remaining warnings on the main pattern were as follows:
[i]Multiple markers at this line
- Inconsistent parameter type definition, should be Sub
based on the pattern definition
- The pattern body contains constraints which are only loosely
connected. This may negatively impact performance. The weakly
dependent partitions are: [ID This ][X Y Z T K ][/i]
The second one can be neglected for the being, since the performance is not a priority for me. But the first warning does still interest me.
To your last question, yes, the MyPatternClass was generated in the main package of src-gen, with all the other private helper patterns generated in the util-package. In this class there is the field "fSrc" and the parameter "pSrc" in the class constructor and both are the type of the Sub.
So then, this is a bug, right? I can definitely live with my first approach, where there is only on Super class, but still the second approach -as sad- would be the more preferable option. Is there anything I can do? Delivering more information if you need or opening a bug?
Thanks again for the help!
Best regards,
Emre
|
|
| | | |
Goto Forum:
Current Time: Thu Apr 18 01:32:33 GMT 2024
Powered by FUDForum. Page generated in 0.02786 seconds |
] 
Search
Help
Register
Login
Home
