I made a mistake with this. We now have model validation that prevents this from working in EF Core. So reverting the “completed” status.
Valeriano, it is actually not possible. Since I checked last time, we added model validation that prevents this from working. Thanks a lot for bringing this up to my attention.
I wonder if the problem you are hitting is related to https://github.com/aspnet/EntityFramework6/issues/22. In any case, it would be great if you could report this as an issue in https://github.com/aspnet/EntityFramework6/issues/.
@Marius Vorster: Thanks for the feedback. This is a feature we would like to add in the future. In EF7 we are laying off some of the necessary infrastructure in the form of query annotations, and we would accept a contribution in this area.
In the meanwhile for EF6, at least for very simple cases it is possible to append OPTIONS() at the end of queries using a query interceptor, e.g.:
class SimpleOptimizeForUnknownInterceptor : DbCommandInterceptor
public override void ReaderExecuting(
command.CommandText = command.CommandText +
" OPTION (OPTIMIZE FOR UNKNOWN)";
Of course you will want to add some logic to control when this transformation applies, e.g. add a bool flag to your custom DbContext and then check for the state of that flag inside the interceptor.
That the Create() method should initialize collections makes sense to me (although there might be reasons we didn't do it). Anyway, I renamed the idea so that others can vote for it if they want.
Will, how exactly do you instantiate the entity? I am asking because I want to understand exactly what your expectations are. If you are using the new keyword in C# or VB to instantiate your entity then EF has no saying on the contents of your collections.
@abatishchev: Of the 17 "under review" ideas I looked at today are actually already being implemented in EF7, and at least one has been completed already for EF 6.1.2, and some are still being considered, just not committed to a release.
The feedback we get in this UserVoice site is fundamental to our planning and prioritization, even if many great ideas haven't been implemented yet and we don't know exactly when we are going to implement them. I prefer to be upfront about that and I realized earlier today that we were using the "under review" status incorrectly to tag ideas that we thought were very good rather than as an intermediary step that should lead to "planned", "started", "completed" or to "rejected" once reviewed.
On the other hand, since we started this UserVoice site we have completed or started to implement about half of the top 40 voted ideas. We have also implemented many of the top voted issues in our bug database at CodePlex:
Hi Eric, what you are seeing doesn't sounds like the expected behavior. We usually do put the generated complex types in the same namespace as the entity types. Could you file a bug and provide a repo? https://entityframework.codeplex.com/WorkItem/Create
By design the use of Include in a query only conveys the need to traverse a path of navigation properties and to load the associated objects found in the path. It does not apply filtering to the root query on which it is called.
To implement Include with these semantics, EF needs to use LEFT OUTER JOINs in the general case.
In EF5 and the updates to the EF core libraries in .NET 4.5 we made the query logic smarter to take advantage of additional information to decide when it is ok to use INNER JOIN instead of LEFT OUTER JOIN. E.g. if Include traverses a navigation property based on a non-nullable foreign key (i.e. a one-to-many association, as opposed to a cero-or-one-to-many association), it will use INNER JOIN because it knows that the starting entity will always have an associated entity on the other end.
I would expect this improvement to help improve performance in many cases.
On the other hand, what this idea is proposing seems to be an alternative to Include that filters the root query to only return objects that have associated objects in the path. I can imagine such alternative looking something like this:
var q = db.Customers.IncludeRequired(c => c.Orders);
Issue tracking this feature: https://github.com/aspnet/EntityFramework/issues/1833.
I have moved this idea from WCF Data Services to Entity Framework as it seems to refer to EF.
Reset status to reflect state in EF Core.
This was contributed to EF 6.1.2 by BrandonDahler in this PR: http://entityframework.codeplex.com/SourceControl/network/forks/BrandonDahler/EntityFramework/contribution/7352
Hello, this suggestion seems to combine a few interesting ideas to extend LINQ to Entities: provider specific extensions, expandable expression methods and client side evaluation. It would be worth discussing and elaborating the details a little more.
I would like to encourage you to start a discussion on our codeplex site.
Regarding the supposed "magic" that let us process extension methods such as Where regardless on whether they are the version defined for IQueryable<T> or IEnumerable<T>, we rely completely on the compiler. The only time LINQ to entities sees the IEnumerable version is if it got captured by the compiler in a nested expression, i.e. it wasn't executed.
Reverting status from “under review” to “no status” since we aren’t currently working on this. We will still consider it for future releases.
15 votesAdminDiego Vega (Program Manager, Microsoft Entity Framework) shared this idea ·