MDA transformation for DDL has default FK NotNull

[FritzTheCat]

Hello
not sure if I picked the right forum, please give me some advice if not.

I'm using MDA transformations to create a Data Model (PSM) out of a Plattform Independant Model (PIM).
Until build 833 an association between two classes in the PIM resulted in a nullable Foreign Key in the PSM, with 833 the default changed to NotNull.
I'm not fully documented on the change, how to influence the default or so, but I think this will brake models that are fine before 833!
The change was after all requested by me, as of my understanding, we had some communication problems after all.

I need a way to tag or whatever the PIM, so that the PSM (Data Model) will be using NotNull FK or Nullable FK, but the decision is done in the PIM.

Does anybody use the MDA style DDL transformations after all?

Step 1:
I would suggest that the transformation, where one defines the foreign key, is the place where the NotNull token is used on the source attribute to "mark" for NotNull foreign key. The foreign key should default to Null, if no NotNull is used here (this is in the transformation from PIM to PSM).

An option would be a defined tag on the association (not my favorite) to set Null or NotNull.

Step 2: is to invoke the Code Engineering -> Generate DDL that does create the DDL. This Part works fine in 833, so it creates Null or NotNull FK based on Nullability of FK Attribute.

Hope this is clear somehow, please let me know if not.

Check your PIM if it will stand the upgrade to 833 after the default changed from Null FK to NotNull FK ! [smiley=thumbdown.gif]

Greetings
Peter

[«Midnight»]

I was caught a bit off guard by this as well, but have not yet had time for a full test.

There are many common scenarios - such as the UML metamodel itself for example - where a child element has a parent with multiplicity of [0..1]. This would be modeled with a foreign key that could be null.

So, is this a defect, or is it a (possibly breaking) change?

[FritzTheCat]

The [0..1] multiplicity on the association would be a fine thing, the Code Engineering DDL would need changes for that to create the correct DDL.
That said, what would the Code Engineering DDL thing (is it a tool?) do with foreign key attribute set to NotNull and source side of the association having multiplicity of [0..1]  

It would have to be documentet somehow, after all

[«Midnight»]

Sorry, I didn't make myself clear. I agree with you on this. What I was questioning was whether Build 833 had introduced something that wasn't quite right.

Either way I certainly agree that it should be documented.

[FritzTheCat]

Just a short update:
I also posted to the support and was given a short feedback. Someone is looking for a fix or whatever. I'm not at all sure if the fix will be based on multiplicities of the association or if the FK in the transformation can be  set NotNull with the default changed. I have no idea when the fix will be available.

If someone wants to give some input (Midnight seems to be kind of a reference) please go ahead.

Greetings
Peter

[FritzTheCat]

This was changed and fixed and changed and fixed, as of 8.0, it is very stable and useful imho