PS, through doing this I've found that there's a number of ways the surrounding code could be refactored to make something like this easier to update -

• The status of "virtual relation-created column" - eg, a column that has been created as part of a relation existing without
  an explicit column already being there is mostly implied through a few particular field checks. This should be codified
  either as a getter or as a property that gets set when the ColumnMetadata is created
• Embedded column code is just peppered throughout everything. It might be worthwhile to have a separate layer - eg, an EmbeddedColumnMetadata extends ColumnMetdata - to support this logic instead of the if blocks.. As it stands, it adds a lot of complexity to the classes.
• One thing I've found is that there's a number of footguns in the configuration of a schema. It might be worthwile to clamp down on support of features with more explicit error messages being thrown instead of letting things get in a state that's broken. Buuut... that's a bit more vague to implement.
• Not everything is the same between decorators and the entity schema. You can create some things in decorators that you can't in EntitySchema and some of the namings aren't quite the same. Not sure the best way to fix that, though, without breaking backwards compatibility.. There's also a number of defaults present in the decorators that aren't in EntitySchema - though in some cases it's because the decorators have more knowledge of where they're being associated..

I just raised an issue which I think is linked to this: #10450

In my case the composite primary key being updated includes the foreign key to the parent and you get a constraint error. When updating a child with a single primary key or a composite key that does not include the foreign key, updating works ok.