Hi all, I am developing course material for the Mendix course at TU Eindhoven. I am concerned about the following: I am unable to use modules meaningfully. More specifically, I am unable to realize the following: define an entity Ea in module Ma (in project Pa), import module A in project Pb (via the MPK export), in project Pb, define a module Mb with an entity Eb, define a one-to-many relation from Eb to Ea (which AFAIK needs to be defined as a many-to-one relation from Ea to Eb in Mendix, and which is IMO the cause of the problem...), try to import Ma and Mb in another project... this seems impossible. In step 4, we are forced to introduce a dependency from Ma to Mb, so both modules are now mutually dependent. Therefore, neither Ma nor Mb can any longer be properly imported in isolation (whereas conceptually Ma does not depend on Mb). I have tried to export project Pb (the one holding Mb and the import of Ma) completely to an MPK file but when I try to import that as a module into another project (say project Pc), I get the error "Module '' not found in pacakge". When I try to import the Ma and Mb individually, the cross-module association gets lost. Is there a workaround to have cross-module 1-* associations that are owned by an imported entity? It seems to me that in the longer term it should be supported to change the owner of such associations (have them owned by the 1 side) but it would be nice already if there is a less elegant solution in the meanwhile. Sincerely, thanks a lot in advance, Pieter Van Gorp PS: I very much like the UML inpired association cardinality syntax in 2.5.2 (this is the first time I used it after using 2.4.6 and 2.5 beta during a Mendix training). Keep up the good work.
asked
Pieter Van Gorp
2 answers
1
Hi Pieter,
It seems to me that in the longer term it should be supported to change the owner of such associations (have them owned by the 1 side).
At the moment this isn't possible without affecting the multiplicity as you stated in the comments:
I expected this freedom of choice, since it is supported by UML class diagrams. There, there *is a separation between the association end multiplicity and its navigability.*
We are aware of this limitation. In 2.5 we did only update the notation of the domain model. The next time we will do updates to the Domain Model DSL we will do some major changes and at that moment we will also consider the mentioned issues.
For the moment I hope your students will like the UML syntax as opposed to the previous 'hierarchical-notation'.
answered
Johan den Haan
0
You can already set the owner of an association. i.e. the object from which you start to create an association is the owner. However, when you import a module i don't think associations to external modules are also exported because you can't change the origin or target of an association, so it is useless to export that specific association.