Description
McJoe Mayorga created an issue — 7th April 2008, 15:35:54:
The fix to NH-901 breaks the following prior
ComponentTypebehavior (from reference doc):Like all value types, components do not support shared references. The null value semantics of a component are ad hoc. When reloading the containing object, NHibernate will assume that if all component columns are null, then the entire component is null. This should be okay for most purposes.
As of 1.2.1, the component will no longer be null. Any value type struct member T will now get initialized to default(T), which may produce unwanted behavior. Sample test attached.
Karl Chu added a comment — 23rd April 2008, 18:34:11:
What is "unwanted behavior" is debatable. If one uses a struct, one wants value semantics. What would be the reasons to use a "nullable struct" instead of making it a class?
McJoe Mayorga added a comment — 7th May 2008, 16:28:25:
The example above is a bit contrived. A better one would be something like LocalizedPrice, which contains a price and a currency. This is pretty naturally a struct. We need to differentiate between null values (payment pending, say) and defaults (voided payment in default currency) .
Fabio Maulo added a comment — 12th July 2008, 22:34:19:
The problem is something more deep than appear.
With NH-901 we are allowing the use of value type like component.
In NH-1284 the user want use a component in a nullable property.
The real underlining type of "Address?" is not "Address" but "System.Nullable<Address>".
If the user map the Type "Address" (a struct) NH don't have a way to know that it is nullable.
If the user don't map the type NH can't find "System.Nullable<Address>".
More than a bug it appear like a limitation so the issue can be converted to improvement.What we need is to catch the real type of the property (in this case "
System.Nullable<Address>") and create mapping info for underlining type.
We can't fix it for NH2.0.0.
Fabio Maulo added a comment — 12th July 2008, 22:47:50:
Added test to the trunk.