I just upgraded my project to use NHibernate 1.2.1 instead of 1.2.0, for the purpose of using NH-901, ironically enough.

While, I believe NH-901 may have been resolved with the change to Hydrate which was mentioned in the Jira, I believe this broke behavior that worked in prior releases, and I would even say it should be intended behavior.

Basically, Hydrate now checks to see if the entity is a value type or not. If the object is a value type it always returns the array of values (even though they are all null). Previously it would return null if the all of the values within the component were null.

What's missing is that Nullable<> is in fact a ValueType which contains conversions for null. Instead I think this code should check if it is a value type and is not generic or is both generic and it's generic type definition is Nullable<>. If the value type is a Nullable<> type then it should behave in the same manner as it used to. If the value type is not Nullable<> then it should use the new behavior.

It's possible there is a more elegant solution to this problem, but this is the solution I know of.

For more information I tried to resolve this issue myself, but to no avail. The componentClass property that I was checking to see if it was Nullable<> or not was not actually Nullable<>. It turns out that if I let reflection determine the type of component it throws an exception. If I define the full type with the System.Nullable`1 syntax it also throws an exception. Therefore at the time of hydration I do not actually know if it is a nullable type or not.

I think this issue involves more changes to the way the mapping files are parsed.

The suggested solution would not work for older programs (like ours) which use the Nullables. Also in that case, a NullableInt32 (e.g.) which is stored as NULL in the database is returned in the values array as an object with "HasValue == false" - but the surrounding logic seems to conclude from this that the component is NOT null, even though the NullablyInt32 with HasValue == false is "logically" a null ...

Any solution to this around the corner (or somewhere else)??

Regards
Harald

Actually, I am not sure that the previous poster and I talk about the same problem - however, here is what we changed in ComponentType.Hydrate to keep the original behavior for (the old) Nullables:



is now



- with, unfortunately, the consequence that NHibernate now references the Nullables project ...

Is this a bug ( that should be reported to JIRA - or is it already there)?

HM

(Me once again replying to myself - just to somewhat "close the issue")

The problem is actually in all versions of NHibernate: When you use a component containt a Nullable from the contributions, the "all values null leads to component is null" logic does not work. The reason is that (in 1.2 - but apparently also in earliert versions) ComponentType.Hydrate checks for instead of the IMHO more correct

After looking into some more code, I'll try to open an issue.