Implicit change sequence order assumptions in Reactions #3
Replies: 1 comment
-
Original comment by @HeikoKlare:It's great that you bring that topic up. And I totally agree: we have these assumptions about the order of changes, for which one might say that the transformations with these assumptions only work "by accident". We have been knowing this for a long time and in some transformations, we have already considered how "correct solutions" (to be explained in the following) have to look like. But as you point out, most transformations make (too) strong assumptions that will not always hold. First, I want to make some extensions to the discussion about what we would like to have, because from my point of view it is essentially not about change orders, as it's not that simple as only having a rename before an insertion (because that is also a strong assumption about how transformations work that does not always hold). Instead, it is about how changes are or have to be processed. In fact, many transformations (at least the ones we consider), even if implemented imperatively and change-driven, are relational. They match some pattern and in case a pattern matches they create some other pattern, which is then kept consistent afterwards. This is how relational languages, such as our Mappings language, work by design. In consequence, the same applies to the createOrFind pattern. Its application has to be delayed until all information required for a pattern match are given. This does not mean that only the name of the element must have been set. Since most elements can be uniquely identified by their names, this works out for most of the scenarios we have by now, but actually this is only a "case-specific-sufficient" solution, but not a conceptually sophisticated one. This is also why enforcing a specific change order is not reasonable (change order depends on how changes occurred, not how they are used) and, unfortunately, not an ultimate solution either. We can, of course, discuss how to improve the Reactions language to support this pattern matching properly. However, there is the risk that we result in an overly complex language that partly replaces the Mappings language, which is actually intended to provide the relational specification of transformations, from which the required pattern matching is automatically derived. Originally, the Mappings language was intended to be used whereever possible (to abstract away from manually performing pattern matching) and to only use or adapt Reactions where necessary. Since the language is not in a state that can be used productively, we may either make that language ready-to-use, or throw it away and grow the Reactions to a one-fits-all solution. As a side note: Instead of the Mappings we may even use the Commonalities language as an even more sophisticated replacement. As you see from my post, this is a quite complex topic that we should discuss in a meeting and figure out how to proceed with the transformation language we have. It requries some holistic considerations and discussion, such that we should not implement some quick-shot solutions for that. |
Beta Was this translation helpful? Give feedback.
-
For (almost) all our current applications, we make strong assumptions about the order in which objects are created. In particular, it is expected that an object is named before it is inserted (otherwise the createOrFind pattern does not work) and even more critical, all other changes to the object are expected to be executed after the insertion. If this is not the case, changes to an object performed prior to insertion are lost in the target model, as all such routines require an already setup correspondence. Currently, this can only be fixed by updating all attributes of an object when it is created, leading to a lot of code duplication (thus it's never done in the current code).
Therefore, it was desirable to solve this in the future as part of the language / the engine. Approaches for this could be to automatically reorder the changes such that naming and insertion are performed first. Another approach could be to extend the language by some await correspondence construct which queues up the routine until some correspondence is created. Furthermore, currently we assume for createOrFind to work that an object is inserted and named thus it would make sense to allow compound triggers only for creation scenarios with required values, like created and features [name, eContainer] set.
Beta Was this translation helpful? Give feedback.
All reactions