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.

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

Query: projecting naked correlated collection when tracking should return collection object of it's parent entity #14046

Closed
maumar opened this issue Nov 30, 2018 · 2 comments

Comments

@maumar
Copy link
Contributor

maumar commented Nov 30, 2018

when we issue this query:

customers.Select(c => c.Orders)

currently we generate a new instance of Orders collection type. Instead we could/should grab the collection instance from the parent entity and use it instead. This way we can better handle all exotic cases, where customer collection is exposed as interface, doesnt have parameterless ctor etc.

In fact, we could potentially leverage include pipeline for this case. Include gets parent entity and collection of its children, associates them together and returns the parent entity. For this case the only difference is that we have to return collection instead.

@ajcvickers
Copy link
Member

Triage: Added a reference from the 3.0 queries issue.

@divega
Copy link
Contributor

divega commented Jan 25, 2019

This was discussed recently in a design meeting and the conclusion was:

We will keep the current behavior for now unless a customer asks for this to be fixed or we need it to fix a different issue.

This means:

  • EF Core’s change tracking never tracks collections, unless they are part of an entity
  • A query like this will always return a new, non-tracked instance of the collection type (though the elements of the collection can be tracked), if the collection type is something we know how to instantiate
  • It will throw if we don’t know how to instantiate. You can add something like ToList() as a workaround
  • We will not try to get the collection instance from the principal entity
    • neither as a strategy to instantiate the collection,
    • nor as a way to make sure we return the same collection that is already loaded when the principal entity is loaded,
    • nor as a way to obtain a collection that is fully tracked and for which additions and deletions have consequences,
    • nor as a way to upfront load a collection that then we fix up to the principal entity when it is later loaded

The behavior could be somewhat misleading, but in several years and several O/RM products that support LINQ, we haven’t seen significant evidence that this type of behavior causes bad problems.

@divega divega removed this from the 3.0.0 milestone Jan 25, 2019
@smitpatel smitpatel removed their assignment Jan 12, 2022
@ajcvickers ajcvickers reopened this Oct 16, 2022
@ajcvickers ajcvickers closed this as not planned Won't fix, can't repro, duplicate, stale Oct 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants