AdminDiego Vega (Program Manager, Microsoft Entity Framework)

My feedback

  1. 9 votes
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)

      We’ll send you updates on this idea

      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.

    • 214 votes
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        Signed in as (Sign out)

        We’ll send you updates on this idea

        This is something we can consider in EF Core if at some point we implement change tracking proxies.

        From the EF6 perspective we don’t plan to change the current behavior. An important part of the motivation to create change tracking proxies is to avoid the cost of performing data comparisons.

        @Jon that is when proxies (or some other way of rewriting the user provided code) could help, and we currently don't have proxies for EF Core, but that is a completely separate feature request from what this was about.

      • 4 votes
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          Signed in as (Sign out)

          We’ll send you updates on this idea

          AdminDiego Vega (Program Manager, Microsoft Entity Framework) supported this idea  · 
        • 1 vote
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            Signed in as (Sign out)

            We’ll send you updates on this idea

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

          • 192 votes
            Sign in
            Check!
            (thinking…)
            Reset
            or sign in with
            • facebook
            • google
              Password icon
              Signed in as (Sign out)

              We’ll send you updates on this idea

              @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(
              DbCommand command,
              DbCommandInterceptionContext<DbDataReader> interceptionContext)
              {
              command.CommandText = command.CommandText +
              " OPTION (OPTIMIZE FOR UNKNOWN)";
              base.ReaderExecuting(command, interceptionContext);
              }
              }

              Usage is:

              DbInterception.Add(new SimpleOptimizeForUnknownInterceptor());

              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.

            • 4 votes
              Sign in
              Check!
              (thinking…)
              Reset
              or sign in with
              • facebook
              • google
                Password icon
                Signed in as (Sign out)

                We’ll send you updates on this idea

                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.

              • 965 votes
                Sign in
                Check!
                (thinking…)
                Reset
                or sign in with
                • facebook
                • google
                  Password icon
                  Signed in as (Sign out)

                  We’ll send you updates on this idea

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

                  https://entityframework.codeplex.com/workitem/list/advanced?keyword=&status=Closed&type=All&priority=All&release=EF%2b6.0.0%7cEF%2b6.0.1%7cEF%2b6.0.2%7cEF%2b6.1.0%7cEF%2b6.1.1%7cEF%2b6.1.2&assignedTo=All&component=All&reasonClosed=Fixed&sortField=Votes&sortDirection=Descending&page=0

                • 3 votes
                  Sign in
                  Check!
                  (thinking…)
                  Reset
                  or sign in with
                  • facebook
                  • google
                    Password icon
                    Signed in as (Sign out)

                    We’ll send you updates on this idea

                    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

                  • 114 votes
                    Sign in
                    Check!
                    (thinking…)
                    Reset
                    or sign in with
                    • facebook
                    • google
                      Password icon
                      Signed in as (Sign out)

                      We’ll send you updates on this idea

                      AdminDiego Vega (Program Manager, Microsoft Entity Framework) supported this idea  · 
                    • 7 votes
                      Sign in
                      Check!
                      (thinking…)
                      Reset
                      or sign in with
                      • facebook
                      • google
                        Password icon
                        Signed in as (Sign out)

                        We’ll send you updates on this idea

                        AdminDiego Vega (Program Manager, Microsoft Entity Framework) supported this idea  · 

                        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);

                      • 865 votes
                        Sign in
                        Check!
                        (thinking…)
                        Reset
                        or sign in with
                        • facebook
                        • google
                          Password icon
                          Signed in as (Sign out)

                          We’ll send you updates on this idea

                          I have moved this idea from WCF Data Services to Entity Framework as it seems to refer to EF.

                        • 6 votes
                          Sign in
                          Check!
                          (thinking…)
                          Reset
                          or sign in with
                          • facebook
                          • google
                            Password icon
                            Signed in as (Sign out)

                            We’ll send you updates on this idea

                            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.

                          • 69 votes
                            Sign in
                            Check!
                            (thinking…)
                            Reset
                            or sign in with
                            • facebook
                            • google
                              Password icon
                              Signed in as (Sign out)

                              We’ll send you updates on this idea

                            • 15 votes
                              Sign in
                              Check!
                              (thinking…)
                              Reset
                              or sign in with
                              • facebook
                              • google
                                Password icon
                                Signed in as (Sign out)

                                We’ll send you updates on this idea

                              Feedback and Knowledge Base