When I load an object, then set a 1:1 property that has not lazy loaded yet to null, it does not clear the underlying FK field.

example: ClientEntity client = new ClientEntity(id); client.Login = null; After the above, I would think that client.LoginId (the FK field) would also be null, but it is still the original value.

Is this the correct behaviour?

SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll version: 3.0.10.0915

And what happens when you do the following:

ClientEntity client = new ClientEntity(id);
client.Login = new LoginEntity();

That does work as expected and clears the FK field.

The issue looks like it is in EntityBase.SetSingleRelatedEntityNavigator. It only does the UnsetRelatedEntity if currentValue != null.

Tht\s because the property was null by defaultm and so setting it to null changed nothing.

True, the property is null, but it is attached to a FK field that "should" be kept in sync.

brianchance wrote:

True, the property is null, but it is attached to a FK field that "should" be kept in sync.

Yep. But the FK/PK sync never took place coz you never load the related entity. In my opinion this is expected, as the value isn't changed. If you want that, you should load the related object and then set it to null (that will work) or just set the field to null. (more info about this...).

I can understand why one wants this, but I have no idea what the effect will be when introducing this. The problem is that IF this is introduced, code which works fine today might not work anymore, because some developer sets properties in a loop and didn't check for null.

The reason I see why one wants this is that you don't have to know the FK fields to reset them: just set the navigator to null, and the FK fields are changed.

So fixing it is a breaking change which we won't make now. I'll add a workitem for v3.2 to look into this to see whether it needs changing/adding.

The behavior as it is now is how it is since the beginning 7 years ago: the property hasn't been set to a value (yet) so setting it to null is a no-op.

I totally understand the breaking change issue and appreciate you looking into it. For now I will just make sure I get the property before setting.

Maybe making the method virtual so it can be overridden in CommonEntityBase would work?