Open eclipse-qvtd-bot opened 6 days ago
eclipse-qvtd-bot
commented
6 days ago By Ed Willink on Aug 15, 2016 09:47
First attempt to run fails at an ObjectManager consistency check. There is a missing enforcement of the uniqueness of EList content; EMF does not enforce uniqueness.
eclipse-qvtd-bot
commented
6 days ago By Ed Willink on Aug 16, 2016 03:56
(In reply to Ed Willink from comment #1)
First attempt to run fails at an ObjectManager consistency check. There is a missing enforcement of the uniqueness of EList content; EMF does not enforce uniqueness.
addAllUnique added for use by the CG, but perhaps it wasn't necessary. THe underlying problem was that partitioing of the four complex/primitive attributes combinatiokns leads to four speculation partitions that are two almost identical pairs; same thing gets dome twice, leading to double results. Should be fixed by a micro-mapping merge.
Next problem is that FromAttribute.owner can be set in the same micro-mapping as its opposite FromAttributeOwner.fromAttributes, making it difficult to satisfy the all-write-before-any-read execution requirement.
The FromAttributeOwner.fromAttributes is PREDICATED but its value is irrelevant. If we distinguish - PREDICATED_REQUIRED (matched) from PREDICATED_OPTIONAL (used), the PREDICATED_OPTIONAL can be partitioned into a separate micro-mapping ensuring that all the writes occur before any reads.
(In reply to Ed Willink from comment #0)
The problem is that currently that rule only transforms AttributeToColumns contained in ClassToTables.
I don't see this. The per-attribute columns all appear in Tables via ClassToTables. Intermediate storage in FromAttributeOwner accumulates for simple and complex. Maybe once it works?...
eclipse-qvtd-bot
commented
6 days ago By Ed Willink on Aug 16, 2016 04:11
(In reply to Ed Willink from comment #2)
addAllUnique added for use by the CG, but perhaps it wasn't necessary.
New Bug 499718.
If we distinguish - PREDICATED_REQUIRED from PREDICATED_OPTIONAL
See Bug 499432
| --- | --- | | Bugzilla Link | 499662 | | Status | NEW | | Importance | P3 normal | | Reported | Aug 15, 2016 09:46 EDT | | Modified | Aug 16, 2016 04:11 EDT | | Depends on | 499432 | | Reporter | Ed Willink |
Description
Created attachment 263593\ test example
From Horacio's email of 8-June-2016:
I have attached a version of the SimpleUMLPeople model (you might need to fix the references to the metamodel location) which includes some complex and some complex-complex attributes. I don’t know if you have run your tests with a model that actually triggered execution of the complexXXXX mappings.
I think there is a problem with the QVTc transformation, specifically in the attributeColumns rule. The problem is that currently that rule only transforms AttributeToColumns contained in ClassToTables. When transforming complex and complex-complex attributes, the attribute to columns end contained in their parent NonLeafAttribute. For the first level complex attributes this is indeed the ClassToTable, but as you visit nested complex attributes this is no longer the case. Hence, the attributeColumns rule must be modified to search for all AttributeToColumns in NonLeafAttributes and the correct table must be found by doing a search in the closure of the NonLeafAttribute owner till a ClassToTable is found.
:notepad_spiral: ComplexUMLPeople.xmi