Home » Modeling » VIATRA » Querying FeatureMap constructs ?
| |
Re: Querying FeatureMap constructs ? [message #1790130 is a reply to message #1789958] |
Tue, 05 June 2018 15:18 |
Messages: 23 Registered: September 2015 |
Junior Member |
|
|
Hi Zoltán,
According to the example in the EMF document here: https://www.eclipse.org/modeling/emf/docs/overviews/FeatureMap.pdf
preferredOrders and standardOrders are the two derived features, orders is the EFeatureMapEntry containment attribute.
Let's imagine a root Model element classically containing suppliers.
As expected:
matches the model and each of its owned suppliers
matches all the Supplier objects
Using derived features:
Supplier.preferredOrders(s, po); matches suppliers and their preferred orders, meaning that the generated implementation is well behaving. Great !
As the global orders list is not usable, I could write an OR pattern combining all the derived features.
=> For the sake of simplicity, we could imagine Viatra Query to give the same matches when querying an EFeatureMapEntry[0..*] attribute: some kind of:
Supplier.orders.value(s, po); but I guess nor orders nor value would notify any change.
On the dark side of the FeatureMap:
doesn't match any object, that's the case I mentioned as being contained beneath a feature map. The containment is not a classical composition, but the composition of EFeatureMapEntry-ies containing PurchaseOrder-s as their value java property.
PurchaseOrder.anotherFeature(po, sth); wouldn't match anything. I can only suppose that it's because no PurchaseOrder is found, as stated in the previous point.
=>These two last points definitely make Viatra Query unefficient with feature maps.
Hope this helps to clarify the problem.
Please tell me if you want me to write a bug report.
Cheers,
--Eric
[Updated on: Tue, 05 June 2018 15:19] Report message to a moderator
|
|
|
Re: Querying FeatureMap constructs ? [message #1790137 is a reply to message #1790130] |
Tue, 05 June 2018 18:27 |
Zoltan Ujhelyi Messages: 392 Registered: July 2015 |
Senior Member |
|
|
Hi Eric,
thanks for the more detailed description, it is somewhat clearer to me what your issue is. Yes, given VIATRA does not allow you to specify edges around EFeatureMaps; I'd go with the or pattern construct you have mentioned earlier as a workaround. I'd mention that you could create a library (basically a separate file with these queries), so you don't have to pollute your main query definitions with these helper patterns.
The second case on the other hand clearly feels like a major issue in VIATRA that we should fix as soon as possible. Given the way the issue manifests itself, I believe you are using an older version of VIATRA (older than 1.6), because in newer versions with default settings Suppliers.preferredOrders(s, o) should also not return anything if PurchaseOrder(o) result in an empty match set as well.
A bug report would really be helpful; and if you could at least point us to a metamodel that has such a problematic construct included that would help a great deal of finding the issue in our codebase, as we would not need to create a domain that demonstrates the issue before we could check anything. Looking at the domains I am familiar with I did not find any containment-based feature map usage like this.
Thanks again for the detailed explanation and your willingness to help,
Zoltán
|
|
| | |
Re: Querying FeatureMap constructs ? [message #1790514 is a reply to message #1790472] |
Tue, 12 June 2018 08:47 |
Gabor Bergmann Messages: 36 Registered: July 2009 |
Member |
|
|
Hi Eric,
it would be very helpful if you could provide a public example where VIATRA is failing in the way you described, because the issue seems to be difficult to reproduce.
Specifically, I started from the usual library.xsd example, and wrapped the 'books' and 'writers' containment references into an xsd:choice. Viatra Query seemed to work well (or at least the v2.0 RC that I tried it with, though I do not expect that this functionality was impacted between 1.5 and 2.0).
Just a stray thought: is it perhaps possible that in your orders example, the `preferredOrders` EReference is, mistakenly, not set as containment, and therefore the referred PurchaseOrder object could be out of the EMFScope that was defined for your query engine?
thanks,
Gábor
|
|
|
Goto Forum:
Current Time: Fri Dec 13 10:31:32 GMT 2024
Powered by FUDForum. Page generated in 0.03633 seconds
|