Any chance this will be included in the 2.1.0 release in Q4?
@SneezeWeeze It's currently in the Backlog, meaning it is not planned for the next release.
You can vote for features by using the +1 reaction on the original comment (馃憤)
I don't think #246 should be considered closed without this since enumerables are a very common use case for complex types in the NoSQL world.
But I'd also like to add to this that key-value/dictionary types should be supported, as this is another very common "enumerable" complex type in the NoSQL world.
I don't think #246 should be considered closed...
@crhairr it seems our team just tracks work very differently from what you expect. In case it helps you understand:
Yeah, I saw the dictionary issue earlier and already upvoted it. I meant to come back here and reference it directly to link the two.
As for how you track your work: at every company I've ever been at that uses Agile, the dev team would have gotten yelled at for closing issues when "significant portions" were done, instead of when the issue was "completely done" according to original acceptance criteria. I guess prior management has beaten that into me, so I'll stop paying it forward.
What I'm really interested in is better support for third-party, NoSQL DB providers for EFCore. Complex Type support is a huge part of that and seems like relatively low-hanging fruit given how rich EFCore's metadata system already is. Properly supporting complex types would go a very long way to getting more third party DB providers in play and having a more expanded EFCore community. It would also REALLY help me out with my MongoDB provider.
@crhairr regarding the important of these features for supporting document oriented databases, I think we are in complete agreement.
@smitpatel is currently working on a provider for the Document DB API in Cosmos DB and we hope to learn a lot about what is missing and how to approach document databases in general. I would recommend that you track his steps in this process and that you keep engaging in conversations with us about this. Ideally, your expertise on the MongoDB requirements will help us produce a better design that can accommodate more document database providers easily.
@AndriySvyryd @divega
When will you support this feature 'Collection of Owned Types' ?
@ahmedtolba1984 the plan is to work on this soon after we finish 2.1.
@divega
Thanks :)
This can't happen soon enough. My domain models will be so much cleaner.
@xKloc How are you doing this now? Are you using Value Objects/Owns One?
I'm just curious what are the ways to implement collections of owned types in relational DBs (besides na茂ve serialization to a single cell)?
I'm also wondering (not criticizing), why is this needed at all. If the goal is to support collections of VALUE OBJECTS (DDD), this can easily and naturally (for relational DBs) be achieved with EF entities with shadow id (PK) properties, which would be just mapped to a separate table.
this can easily and naturally (for relational DBs) be achieved with EF entities with shadow id (PK) properties, which would be just mapped to a separate table.
@andriysavin yes, that is more or less one of the possible relational implementations. The feature is also about enabling the concept of collections of owned entities in our metadata and in the model building API, in a way that other characteristics of owned entities are attained. For example, they can only be reached through the owner, there can be multiple navigation properties of the same CLR type, eager loading is automatic, etc.
@divega is implementing this going to help reach for M2M mapping?
@tuespetre Not directly. It's more about aggregates support, which goes to handling documents, which goes to Cosmos DB. The main prerequisites for many-to-many are skip-level nav props and property bag entity types.
@ajcvickers ahhh Cosmos DB, I see now. Thanks
@AndriySvyryd
Thanks. i want to know when this feature will be available???
@ahmedtolba1984 When 2.2 is released, see https://github.com/dotnet/core/blob/master/roadmap.md
@AndriySvyryd Thank you :)
Most helpful comment
@ahmedtolba1984 the plan is to work on this soon after we finish 2.1.