I could reproduce the behavior on v2.0. Very strange. Looking into it.
(edit) also present in v2.5
(edit). The reason is this:
- when assigning an entity to the property mapped onto the relation (in this case assigning an entity to child.Parent), the original one is desynced first.
- when desyncing has to be done, there's no check if the the new entity is the same as the current entity.
- when desyncing, it will reset the FK fields to null. The optional FK fields are nullable, and therefore this will succeed, making them dirty. The not optional ones aren't nullable, and aren't set to null, leaving them untouched.
- after desync took place, the new entity is synced. this will force the FK fields to be set again. This means that the optional FK fields get a value again, and the not optional fields won't be changed as they have the same value.
Normally, this isn't an issue, as you set the 'parent' to a different entity, I mean: why setting it to the same entity? However in the case where you do this, it is indeed leading to unexpected behavior.
This can't be 'changed' without breaking changes as it is a change in behavior. I'll file a change request for v2.6 where this mechanism is re-examined and if possible a check will be introduced which cuts off the whole assignment pipeline if the same entity is assigned to the property.