-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Map part of the entity to Json column without the need of Owned entity container. #30094
Comments
@dsidedp what is your reason for asking for this? What is problematic for you in using an owned entity? |
TL;DR; The real life case is the need to map wide (but not deep) class hierarchy to a table.
By default, all columns in derived classes will have own DB column and I was looking for a way to avoid that. I do understand that there are ways to solve the problem, like
But all of them have some drawback that looks unnecessary. Examples per case above:
This feature will allow devs to avoid of all that - have a better db model, cleaner app model and provide all EF goodies like querying, updates, change tracking. Ability to map to JSON with Owned entity gives almost all that (after json sharing will be allowed), but the need to have Owned entity container seems like unnecessary requirement and something that can be managed by EF, like join entity for many-to-many. |
I'm not sure I understand... Your original proposal above still has a specific number of properties on RangeItem; with the current owned entity model you simply need to move these to a type ("Details") and make it owned by RangeItem... In other words, if we implemented your proposal, how exactly would that help with the "wide class hierarchy" problem? Could you provide a bit more context/code to make that clearer? |
The main difference would be how app classes looks like. Right now, I have to do this:
Configuration supposed to look like this
For each additional descendent of BaseItem I have to declare new class for it's data (like RangeData or MiscData) with the single purpose to be able to use them in OwnsOne method during the configuration. Having 'data' classes will have side effect, most notable are :
This proposal should allow classes to be plain and have configuration like this:
Ofc, each additional descendant will require explicit mapping as well, but the main benefit is we do not have to have all those data classes. I think many-to-many without explicit join class is the best analogy. For many-to-many we use to have class structure like this:
Now, we do not need to declare join entity This |
@dsidedp Can you post both the desired shape of your entity types and the corresponding SQL table schema that they will map to so we can be absolutely sure what it is you want to achieve? |
For class structure like this
Proposed feature should allow DbContext configuration like this:
Migration supposed to create table like this:
In the App, query like this
supposed to produce SQL query like this:
Updates and queries for 'json mapped' properties supposed to be supported as well. This is the one of the benefits in comparison to ValueConverters. Optionally, it will be great if it will be possible to provide JsonPath as part of the property configuration. This might provide even more benefits, so allowing something like snippet below would be great as well.
Hope it help. |
This bears some resemblance to entity splitting, i.e. it configures some properties of your entity to be mapped to a specific JSON property in a specific JSON document (like entity splitting maps some properties to a different table). However, ultimately this would require quite a big effort on the EF side just in order to allow users to not specify a CLR type; the value proposition seems really quite low compared to the big cost this would require. This is also the 1st time someone has expressed the desire to avoid these types. Also, the current way is consistent with how .NET JSON serializers work in general: if you want to serialize .NET objects to a JSON document, then your object graph must correspond to the JSON document structure, with a .NET type being required for each object on the JSON side. I'm not aware of a System.Text.Json mechanism which allows you to specify on some .NET property that it would actually be serialized to some arbitrary JSON property on an arbitrary nested JSON object. So I'm not sure why EF would add support for this either.
I'm not sure that's a good analogy. M2M without join entity significantly simplifies actual LINQ queries - it's not just about removing a CLR type from the model. This isn't really the case here: having to explicitly specify the JSON document property in the query is trivial and doesn't add any complexity, compared to how M2M queries look like with an explicit join entity. So once again, while I agree there's some similarity here, M2M without a join entity seems to deliver far more value/simplification compared to this. |
How about look at this from a different perspective. EF can threat configuration from examples above as instructions how to build implicit Owned entity and then use it internally. For example, configuration below
can be processed by EF (for RangeItem in this example) as :
In this case,
Item 3 is the missing part and unfortunately I do not familiar with EF internals enough to assess complexity. Does this looks better? P.S. |
@dsidedp We discussed this and even if there is some value here, which we are not convinced of, the cost of implementation and maintenance is too high for what that value is. So this isn't something we plan to support in EF Core. |
Ok, and thanks for looking at this! |
Allow to map part of the entity (i.e. multiple properties) to a single Json column without the need of wrapping them into Owned entity.
Given class
configuration could look like
In case of class hierarchy (TPH) reuse of the same Json column should be allowed as well.
This will require something similar to JSON column sharing.
Thanks.
The text was updated successfully, but these errors were encountered: