You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Where i use .OwnsOne(...) | .OwnsMany(...) to represent object's sub-objects.
If i don't do that, during migration creation i get an error becouse some types are not mapped to CLR or something similar.
What if don't want to care about the strucutre of the object, can i avoid to use: OwnsOne/OwnsMany?
I mean i tried same class structure with Ngpl (postgres) specific client (always EF Core version) and in that case i just needed to add a Data annotation above "Data" field and it was able automatically map all sub-objects to and from DB, no even need to touch OnModelCreating (even if there was a FluentAPI method that does something similar it would be already great).
In my particular case i suppose that my POCO object may evolve over time and in some cases there might be a decent amount of sub-classes and i don't want to map them manually in the context each time.
If its not an option, do you think there is a chance to use reflection in order to build those OwnsOne / OwnsMany on runtime?
I made a fast try but without much success.
I also want to avoid to use JsonObject if its still there becouse i want to see object transparently and access its properties without using string search during LINQ queries. Like:
I think the request here is for us to implicitly configure relationships inside JSON document as owned JSON relationships, rather than forcing the user to explicitly configure each navigation. Basically what we did for Cosmos back in 6.0 (#24803).
Otherwise, this could be seen as a partial duplicate of #28871 or #26903 (weakly-typed JSON), although the request here is to map POCOs rather than JsonElement or Dictionary.
AndriySvyryd
changed the title
Ef Core 8 Preview, mapping POCO Object into JSON column without OwnsOne/OwnsMany
Map related entities for JSON columns as owned by convention
Oct 19, 2023
Ask a question
If i didn't misunderstood.
Based on class structure below, to represent LanguageResource_Table i would need to have context similar too:
Where i use .OwnsOne(...) | .OwnsMany(...) to represent object's sub-objects.
If i don't do that, during migration creation i get an error becouse some types are not mapped to CLR or something similar.
What if don't want to care about the strucutre of the object, can i avoid to use: OwnsOne/OwnsMany?
I mean i tried same class structure with Ngpl (postgres) specific client (always EF Core version) and in that case i just needed to add a Data annotation above "Data" field and it was able automatically map all sub-objects to and from DB, no even need to touch OnModelCreating (even if there was a FluentAPI method that does something similar it would be already great).
In my particular case i suppose that my POCO object may evolve over time and in some cases there might be a decent amount of sub-classes and i don't want to map them manually in the context each time.
If its not an option, do you think there is a chance to use reflection in order to build those OwnsOne / OwnsMany on runtime?
I made a fast try but without much success.
I also want to avoid to use JsonObject if its still there becouse i want to see object transparently and access its properties without using string search during LINQ queries. Like:
Include your code
Include stack traces
Include verbose output
Include provider and version information
EF Core version: 8 preview 3
Database provider: Microsoft.EntityFrameworkCore.SqLite
Target framework: NET 7.0
Operating system:
IDE: Visual Studio 2022 17.5
The text was updated successfully, but these errors were encountered: