Today I found a problem with the multiplicity setting “0…1” if the other side of the association is not navigable.
The Image1 shows all the possible combos with aggregation, composition (does not matter in this case) and navigable true/false.
All the “child” classes are set to multiplicity “0…1” -> so they must be nullable.
Well, syncing to ERD show the result depicted in Image2. The aggregation and composition with navigable=false in the class1 role now have an error… What? :-o look at what the red arrow points to… “Nullable = false” ??? :shock:
This later on lends to errors in DDL file (“int not null”), and hbm.xml mappings (not-null=“true”).
I have just discovered a post-it I left with an indication to myself about: "Set multiplicity of non navigable side of the association to 0…1 if the navigable one is set also to 0…1"
So, I have tested this and… voila! the fields in the ERD entity are now nullable, so all goes well Bravo!
This lends me to question myself, is this a BUG or is it a FEATURE? I mean, in order to have these “class2” and “class3” nullables, is mandatory to set the multiplicity of class1 side of both associations also to 0…1 ???
Your finding explains part of the problem. Actually, we treated the multiplicity of non navigable side of an association to be “1”, which causes the column to be non-nullable (nullable = false). Just now, we fixed by treating it as “0”. You can examine the change by setting the multiplicity of non navigable side to be “0” and “1”, and sync to ERD.
[quote=Jick]Actually, we treated the multiplicity of non navigable side of an association to be “1”, which causes the column to be non-nullable (nullable = false). Just now, we fixed by treating it as “0”. You can examine the change by setting the multiplicity of non navigable side to be “0” and “1”, and sync to ERD.
We will send you a patch a.s.a.p.[/quote]
Many thanks again, it is nice to know the reason and have a workaround about this. I am not getting tired if I have to put 0 multiplicity in each non navigable side. So send the patch when you are ready (no need to be urgent)
I see that you nowadays have some more important problems to fix. This one is a little one Don’t worry.
I have been playing with that “0” multiplicity and, yes it works!!
But… yes it also adds an unnecessary field to the navigable side. I mean, in this simple model:
class1 --X-0--------0…1–> class2
There is a class1ID in class2 ERD entity!!
OMG! you can think that I am being paranoid this time :twisted: , but think about what happens when you have a lot of classes that have a non navigable 1-to-1 association with class2… :?: the class2 “table” fill with lots of parent1ID, parent2ID, parent3ID, … :shock: the ERD diagram gets messy almost instantly :roll:
In order to not break the layout of this topic, I will start a new one with a BIG image I prepared to explain this fact.
I mean, I warn you about the side effects of setting the multiplicity to “0” only and let the code generator go wild with it :lol: I think some extra measures will have to be taken. Maybe you (or your engineers) have already taken them. I don’t try to told you how to do things, I want only to inform you :roll:
I believe that it should now behave like what you expected.
Please let me know if this is not the case.
Hi Jick, excuse me for not answer your questions early. I am very busy right now but I will try to post here my findings.
Yes, I tried the patch and it works as expected!! Nice work!
In fact, this new version helped me to discover some old hidden bugs in my ORM code :oops: that were passed by silently with the previous versions :shock: I will tell you why in a future post, in case some of your clients start complaining about “new bugs” introduced by your new version (these “new” bugs are not on your software, but they are visible only with your new version).
All in all, now that this nullable thing is completely fixed, I will suggest a new “feature”:
In non-navigable associations (like all on this post) I think it would be better to interpret “Unespecified” multiplicity in the non navigable side to be 0 or at least 0…1 when the other side is set to multiplicity 0…* or * because if the program does not do this, then the following error is shown when generating code to C# (this should not happen in Java, I guess):
“Nullable foreign key column with uni-directinal relationship is not supported in .NET ORM…”
Think about it. But… maybe this behavior it is what is was designed to be :roll: but it is a bit time consuming. In other hand, if you directly make an 1-to-many (unidirectional) ORM association , it will fail just out-of-the-box, requiring the user to manually change the 1 multiplicity to 0 or 0…1 in the left side.
You can recreate this last case almost instantly, just add an ORM class, and then select “One-To-Many association -> Class”. Then sync to ERD, and then generate code. The same error shows.
BTW, in that error message you also tell the user WHERE the problem is!!! bravo!! :lol: fantastic!! :-o I cannot thank you enough!! (not joking) Bug15b.png Bug15a.png
I will share your feedback with our team. Oh, please notice that there are still warning/errors that have not clearly specified the problem model. I hope you won’t be too disappointed when you see them But as I said, we will keep on fine tuning the warning and error messages by rephrasing them to more informative.