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.

[fredericDelaporte]

Now documented as a possible breaking change, see here.

[naasking]

I had a string column that was used to group entities, and the group of associated entities was loaded via property-ref as an immutable collection, so updating to the 5.2 series broke this.

I worked around it by setting the column to '' for all pre-existing null entries, and then add a where="Len(Column) > 0" clause to the collection mapping. This seems to preserve the original semantics, where all entries with null (now empty string) in the column should load an empty collection, and non-null/empty entries load the group of associated entities.

[gowthambala]

I am running into the same issue. I have one to many mapping and referencing the second table column via property ref. The referring entity from the parent table has null values. there are no foreign keys. This started breaking after I upgraded to nhiberante 5.3. Is there any work around for this?

[fredericDelaporte]

If your have a null value in the property used as a key, do not attempt to use the collection depending on that property. It just cannot work, and was not actually working previously, as stated in comments above.

anything done on the collection was ignored