This improvement has been implemented in EF Core and will be included in 2.1. The issue tracking it is https://github.com/aspnet/EntityFrameworkCore/issues/2272.
@Ivan, What you propose doesn't seem viable: Attributes declarations can only reference very simple expressions. Any identifiers need to exist and be of the right type. What is TotalColumns? If we ever implement this kind of fine control for columns ordering (which doesn't seem a high priority given that we cannot guarantee the order will be preserved after the first table creation), we would probably use a different approach.
Implementation has started in EF Core and the feature will be included in 2.1. Bug tracking this work is https://github.com/aspnet/EntityFramework/issues/242.
@Tyson, we don't intend to build any more features of this magnitude into EF6. We would rather spent the effort of the team on improving EF Core (yes, to continue closing the functionality gap, among other goals). In theory, if someone from the community decided to contribute something like this for EF6, they could try, but the extensive work on validating the feature and the risk for the redesign makes it very unlikely.
@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.
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.
This will be included in EF Core 2.1. Issue tracking it is https://github.com/aspnet/EntityFrameworkCore/issues/9290.
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
This feature is at least partially implemented in EF Core 2.1. There is no custom binding but many additional patterns are now supported by convention, including injecting the property values in the constructor, injecting instances of services also in the constructor and on properties.
Direct mapping to fields was already supported in 1.1.
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);
We intend to enable this scenario as part of value conversions in EF Core 2.1. There won’t be a convention to enable serialization by default but the user can enable this explicitly for a property in configuration.
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.
This will work as expected in EF Core 2.1, after change https://github.com/aspnet/EntityFrameworkCore/commit/4bb6c386ac244ed7ee53c66cfeb13e1d014bbfc5.
For EF6 feedback, please use https://github.com/aspnet/entityframework6/issues.
Good catch guys! The issue is a little more complicated and we need to consider what the ideal behavior is for each specific method, e.g. returning 0 for Max, Min or Average for an empty sequence wouldn’t make sense, however the overloads that take IEnumerable with T not nullable don’t contemplate that the output could be null, and this to me looks more like an oversight in the design of the LINQ operators than an issue in LINQ to Entities.
I will update the text of the idea to only inluclude making Sum of emtpy set return 0, which I believe makes sense.
Reverting status from “under review” to “no status” since we aren’t currently working on this. We will still consider it for future releases.