Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Support collections of owned entities #8172

Closed
AndriySvyryd opened this issue Apr 14, 2017 · 19 comments
Closed

Support collections of owned entities #8172

AndriySvyryd opened this issue Apr 14, 2017 · 19 comments
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-enhancement
Milestone
2.2.0

Comments

@AndriySvyryd
Copy link
Member

No description provided.

@AndriySvyryd AndriySvyryd self-assigned this Apr 14, 2017
@ajcvickers ajcvickers added this to the Backlog milestone Apr 14, 2017
@smitpatel smitpatel mentioned this issue Aug 20, 2017
Closed
@SneezeWeeze
Copy link

Any chance this will be included in the 2.1.0 release in Q4?

@AndriySvyryd
Copy link
Member Author

@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 (👍)

@smitpatel smitpatel mentioned this issue Nov 12, 2017
Closed
@crhairr
Copy link

crhairr commented Nov 13, 2017

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.

@divega
Copy link
Contributor

divega commented Nov 13, 2017 •
edited
Loading

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:

@crhairr
Copy link

crhairr commented Nov 13, 2017 •
edited
Loading

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.

@divega
Copy link
Contributor

divega commented Nov 15, 2017

@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.

@divega divega mentioned this issue Mar 11, 2018
Closed
@ahmedtolba1984
Copy link

@AndriySvyryd @divega
When will you support this feature 'Collection of Owned Types' ?

@divega
Copy link
Contributor

divega commented Mar 19, 2018 •
edited
Loading

@ahmedtolba1984 the plan is to work on this soon after we finish 2.1.

@ahmedtolba1984
Copy link

@divega
Thanks :)

@todd-skelton
Copy link

This can't happen soon enough. My domain models will be so much cleaner.

@kjbetz
Copy link

kjbetz commented Apr 16, 2018

@xKloc How are you doing this now? Are you using Value Objects/Owns One?

@andriysavin
Copy link

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.

@divega
Copy link
Contributor

divega commented Apr 19, 2018

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.

@ajcvickers ajcvickers mentioned this issue Apr 24, 2018
Closed
@divega divega modified the milestones: Backlog, 2.2.0 May 17, 2018
@divega divega mentioned this issue May 17, 2018
Open
13 tasks
@divega divega mentioned this issue Jun 25, 2018
Open
@tuespetre
Copy link
Contributor

@divega is implementing this going to help reach for M2M mapping?

@ajcvickers
Copy link
Member

@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.

@tuespetre
Copy link
Contributor

@ajcvickers ahhh Cosmos DB, I see now. Thanks

AndriySvyryd added a commit that referenced this issue Jun 29, 2018
@AndriySvyryd
Add model building support for collections of owned types.
f54e449 
Add HasKey() to ReferenceOwnershipBuilder
Add missing string overloads of OwnsOne() and HasOne()
Add hiding overloads of HasData()
Sort methods and fix some comments
Move owned type primary key configuration to KeyDiscoveryConvention

Part of #8172
@AndriySvyryd AndriySvyryd mentioned this issue Jun 29, 2018
Merged
AndriySvyryd added a commit that referenced this issue Jul 2, 2018
@AndriySvyryd
Add model building support for collections of owned types.
480fe2c 
Add HasKey() to ReferenceOwnershipBuilder
Add missing string overloads of OwnsOne() and HasOne()
Add hiding overloads of HasData()
Sort methods and fix some comments
Move owned type primary key configuration to KeyDiscoveryConvention

Part of #8172
AndriySvyryd added a commit that referenced this issue Jul 2, 2018
@AndriySvyryd
Add model building support for collections of owned types.
93da2f0 
Add HasKey() to ReferenceOwnershipBuilder
Add missing string overloads of OwnsOne() and HasOne()
Add hiding overloads of HasData()
Sort methods and fix some comments
Move owned type primary key configuration to KeyDiscoveryConvention

Part of #8172
AndriySvyryd added a commit that referenced this issue Jul 6, 2018
@AndriySvyryd
Add change tracking and query support for collections of owned types.
7982cd2 
Improve detection of the inverse navigation for owned types.

Fixes #8172
@AndriySvyryd AndriySvyryd mentioned this issue Jul 6, 2018
Merged
AndriySvyryd added a commit that referenced this issue Jul 6, 2018
@AndriySvyryd
Add change tracking and query support for collections of owned types.
2d51bc7 
Improve detection of the inverse navigation for owned types.

Fixes #8172
AndriySvyryd added a commit that referenced this issue Jul 11, 2018
@AndriySvyryd
Add change tracking and query support for collections of owned types.
0c22bd0 
Improve detection of the inverse navigation for owned types.

Fixes #8172
@AndriySvyryd AndriySvyryd added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Jul 11, 2018
@AndriySvyryd AndriySvyryd removed their assignment Jul 11, 2018
@crhairr crhairr mentioned this issue Jul 19, 2018
Closed
@ahmedtolba1984
Copy link

@AndriySvyryd
Thanks. i want to know when this feature will be available???

@AndriySvyryd
Copy link
Member Author

@ahmedtolba1984 When 2.2 is released, see https://github.com/dotnet/core/blob/master/roadmap.md

@ahmedtolba1984
Copy link

@AndriySvyryd Thank you :)

@JohnGalt1717 JohnGalt1717 mentioned this issue Feb 14, 2019
Closed
@ajcvickers ajcvickers modified the milestones: 2.2.0-preview2, 2.2.0 Nov 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-enhancement
Projects
None yet
Milestone
2.2.0
Development

No branches or pull requests
10 participants
@divega @ajcvickers @SneezeWeeze @tuespetre @AndriySvyryd @ahmedtolba1984 @kjbetz @andriysavin @todd-skelton @crhairr