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.
20 votes1 comment · Entity Framework Core Feature Suggestions » runtime · Flag idea as inappropriate… · Admin →
1 vote1 comment · Entity Framework Core Feature Suggestions » runtime · Flag idea as inappropriate… · Admin →
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/.
3,375 votes73 comments · Entity Framework Core Feature Suggestions » mapping & modeling · Flag idea as inappropriate… · Admin →
Planned post EF Core 2.0. Bug tracking this work is https://github.com/aspnet/EntityFramework/issues/242.
@Dirk Watkins: enums mapped to a table would not be part of the *simple* type mappings and type conversions feature we have planned. Consider voting for https://data.uservoice.com/admin/forums/72025-entity-framework-feature-suggestions/suggestions/2683498.
I have updated this item's title to reflect the fact that unsigned integer properties are currently not supported by EF, neither as keys, nor as regular properties.
436 votes12 comments · Entity Framework Core Feature Suggestions » runtime · Flag idea as inappropriate… · Admin →
@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.
3 votes1 comment · Entity Framework Core Feature Suggestions » tools · Flag idea as inappropriate… · Admin →
In EF7 we already try to use names from the query for tables and range variables, but not for properties of a projection like this. I would suggest you file a bug for this on http://github.com/aspnet/entityframework.
6 votes5 comments · Entity Framework Core Feature Suggestions » runtime · Flag idea as inappropriate… · Admin →
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
280 votes11 comments · Entity Framework Core Feature Suggestions » runtime · Flag idea as inappropriate… · Admin →
5 votes1 comment · Entity Framework Core Feature Suggestions » tools · Flag idea as inappropriate… · Admin →
Note that the EF runtime already supports this but there aren't easy ways to do it in the designer and code first. I am reusing this item to refer specifically to the designer support since we already have another one that covers code first: https://data.uservoice.com/admin/forums/72025-entity-framework-feature-suggestions/suggestions/1953237-code-first-support-for-mapping-user-defined-functi
244 votes3 comments · Entity Framework Core Feature Suggestions » runtime · Flag idea as inappropriate… · Admin →
14 votes2 comments · Entity Framework Core Feature Suggestions » runtime · Flag idea as inappropriate… · Admin →
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);
66 votes3 comments · Entity Framework Core Feature Suggestions » runtime · Flag idea as inappropriate… · Admin →
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.
13 votes2 comments · Entity Framework Core Feature Suggestions » runtime · Flag idea as inappropriate… · Admin →
At least part of 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.
Moved. Thanks for your feedback!