Community
Participate
Working Groups
Currently multi-input mappings produce a multi-dimensional search and polynomial execution time. The three 2-input mappings in UML2RDBMS are not arbitrary inputs. Instead one input is related by a 1:N relationship to the other so that the secondary input could be realized efficiently by a local loop with respect to the first. Outline: there is the root sub-region that is reachable from all inputs. there are further sub-regions that are progressively reachable from fewer inputs. ultimately there are sub-regions reachable only from a single input. The sub-regions form a tree. Between each parent and child sub-region there is often a unidirectional to-one navigation. [The pathological case of the Cartesian product of two inputs has no such navigation.] The inverse is presumably a 1:N navigation, so it should be possible to schedule the N-side sub-region as an N-fold loop with respect to the 1-side sub-region eliminating the secondary input for the N-side sub-region. If some N-side iterations may fail through not-ready inputs, we must use an outer loop over per iteration instances so that no shared computations are lost unless cached in the shared instance. If all iterations are safe, we may loop directly in a single function/instance. Saety is only determinable after scheduling so this should be a late optimisation perhaps accompanying late-merging/
A similar, but cubic, problem occurs for HierarchicalStateMachine2FlatStateMachine where the primary head is a Transition that navigates to a pair of hierarchical States from which a query (logically a closure) provides the secondary heads. There are two parts, a domain computation that may be too hard to analyze and then an iteration. Currently the iteration can be constrained by an ->includes constraint that the scheduler could recognize. If the computation were embedded in the metamodel as a derived leafStates property we could write hierarchicalTransition : Transition { fromState = _ : State { leafStates = _ : Set(State) { fromLeafState ++ _ } }, toState = _ : State { leafStates = _ : Set(State) { toLeafState ++ _ } }, If the external derived property can be used, why not support contextual properties similar to QVTo so that the derived property can be added by the transformation? If a PropertyTemplateItem can be a derived property, why not also a zero argument operation, or even a multi-argument operation?
(In reply to Ed Willink from comment #1) > hierarchicalTransition : Transition { > fromState = _ : State { > leafStates = _ : Set(State) { fromLeafState ++ _ } > }, > toState = _ : State { > leafStates = _ : Set(State) { toLeafState ++ _ } > }, Using plausible collection = object semantics this may just be: hierarchicalTransition : Transition { fromState = _ : State { leafStates = fromLeafState }, toState = _ : State { leafStates = toLeafState }, See Bug 510032 requesting a first class includes represenation for QVTc at least.
(In reply to Ed Willink from comment #1) > If the external derived property can be used, why not support contextual > properties similar to QVTo so that the derived property can be added by the > transformation? See Bug 506817 > If a PropertyTemplateItem can be a derived property, why not also a zero > argument operation, or even a multi-argument operation? Operations as PropertyTemplateItem targets are pretty dubious in bidirectional transformations since an assignment to l-value is required. Derived Properties as PropertyTemplateItem targets are similarly dubious but changeable derived properties are not fundamentally wrong; just unusual.
