Owned type properties trigger table-splitting in EFCore

[crhairr]

This is related to #10269, as per my MongoDB provider.

I'm attempting to use the Ownership mechanism as a stand-in for complex types, but I'm running into several issues.

It looks like the object graph attacher is walking the object graph and attempting to attach the owned entity types as if they were full navigations. For MongoDB this is the incorrect behavior, and it will be the same for other document DB providers. Attempting to attach owned types should be pushed down to the relational layer, since table-splitting on ownership is a relational concept. Attaching actual navigations from one top-level entity to another is fine, but for ownership/complex types, this mechanism should be left up to the provider.

[smitpatel]

@crhairr - I couldn't exactly understand what this issue is. But I have replied for your others issues here #246 (comment)

Table splitting is relational only concept. On Core owned entities are same as normal entities. Relational takes owner & owned entities and puts them in same table, that is what table-splitting is.

[crhairr]

Based on your descriptions, I think I have a better handle on what's going on now. Because owned entities are treated as their own entity types, even if they don't have keys, they still need to be tracked by the state manager. The problem is that the state manager is submitting those "entities" to my MongoDbDatabase facade for saving. For my provider, this is unnecessary since I'm just wrapping the official MongoDB C# Driver which handles the serialization of object graphs. So I just need to add logic to my database facade implementation to ignore any entity type that is owned (as opposed to a full navigation), which is fine for my specific problem.

I was hoping that this behavior could be configurable at the Core level so that developers of document DBs don't have to replicate any sort of "ignored owned entities when saving" mechanism.

On a side note, is there a better place to discuss implementing a third party provider and get advice on working around some of the issues in Core? I've worked around a number of issues so far, but I'd love to get a second opinion. And maybe even help document things that need to be done to implement a provider.

[smitpatel]

I was hoping that this behavior could be configurable at the Core level so that developers of document DBs don't have to replicate any sort of "ignored owned entities when saving" mechanism.

I would think it is better not to have such configuration. While it is intuitive to save owned entities inside the same document as embedded resource, it is not necessary. User can configure it to be own document collection even though being owned entities. In such case a simple configuration at core level is not useful and provider needs to deal with each owned type saving separately.

On a side note, is there a better place to discuss implementing a third party provider and get advice on working around some of the issues in Core? I've worked around a number of issues so far, but I'd love to get a second opinion. And maybe even help document things that need to be done to implement a provider.

@divega would know better.

[divega]

@divega would know better.

@smitpatel Let's chat about alternatives. I think you are probably going to be the best contact for @crhairr and so it depends on where you hang out 😄

[crhairr]

@divega @smitpatel Would it make sense for me to open issues for my findings with "Document DB" in the title and mention either of you? I have several things that I've found that are either bugs or are things that I've had to work around and I'm not sure if my approach was the best way.