Unable to correctly resolve the owner key with null value property

[neseih]

Since NHibernate version 5.2 (commit: 8124cb5) GetKeyOfOwner in CollectionType.cs throws an exception if the property value (in the database) is null.

Exception:

AssertionFailure: Unable to correctly resolve the owner key, property Property for collection SomeChildrenList.
Unresolved value '', key type 'NHibernate.Type.StringType', owner 'Example.SomeEntity'

Mapping (Example.SomeEntity):

mapping.HasMany(m => m.SomeChildrenList)
.PropertyRef("Property")     // Type: String, can be null
.KeyColumns.Add("ReferencedProperty")
.NotFound.Ignore();

There is no ForeignKeyConstraint on Property and ReferencedProperty and both properties are not keys.

[fredericDelaporte]

Which way is it? Does it throw if the referenced entity has the property null, or if the referencing entity has its association null?

[neseih]

It throws if the referencing entity has a property with null. In the example, it would be "Property" that is null and throws the exception when we access someEntity.SomeChildrenList.

[fredericDelaporte]

Considering this case again, it seems to me that somewhat supporting null for a key (the property ref) was an unexpected side effect of #378, which was also causing bugs and has been reverted in #1872.

Associating entities with a null value is quite a debatable semantic. Indeed, on 5.1.x, it does not work either. Accessing the collection does not throw, but adding items to it is ignored. They get lost. I do not think this behavior was better than throwing right away.

So this could be fixed in two ways:

• Just document this end of partial null support as a possible breaking change.
• Support that special case again.

[neseih]

Hi @fredericDelaporte,

thanks for investigating. For me, readonly access would be enough as I can't have a ForeignKey for different reasons. So if the property ref is null and empty (or null) collection is returned. That worked in previous releases and would be a non breaking change.

[fredericDelaporte]

The more I consider this, the more I think we should:

document this end of partial null support as a possible breaking change.

From a correctness standpoint, there is no point introducing back a bugged behavior, where one could access a non-functional collection without having any error raised, although anything done on the collection was ignored. That breaks the least surprise principle. When something does not work, it should throw, rather than silently do nothing.

This means for your case that you have to check your referenced property before accessing the collection : if it is null (or string.Empty with Oracle, due to that database behavior on empty strings), skip any operation on the collection.