DbSet.Local does not automatically call DetectChanges

[fiseni]

If child is removed from parent's collection, the child's FK is not null when accessing through Set<>.Local property. If we analyze further, we see that CurrentValue is set to null, and I assume it returns the OriginalValue (not null). I'm not sure if this is done by design on EF Core (EF6 has correct behavior). The relationship is nullable.

    public class Order
    {
        public Order()
        {
            this.OrderLines = new HashSet<OrderLine>();
        }
        public int OrderID { get; set; }
        public string OrderDescription { get; set; }
        public virtual ICollection<OrderLine> OrderLines { get; set; }
    }

    public class OrderLine
    {
        public int OrderLineID { get; set; }
        public string OrderLineDescription { get; set; }

        public int? OrderID { get; set; }
        public Order Order { get; set; }
    }

    class Program
    {
        static void Main(string[] args)
        {
            //dotnet ef database update -c AppContext
            //SeedData();
            DoTest();
            Console.ReadLine();
        }
        private static void DoTest()
        {
            var context = new AppContext();
            var order = context.Orders.Include(x => x.OrderLines).FirstOrDefault();

            Console.WriteLine("Before Removal");
            foreach (OrderLine item in context.OrderLines.Local)
            {
                Console.WriteLine($"OrderLine ID: {item.OrderLineID}, OrderID: {item.OrderID}");
            }
            Console.WriteLine();

            order.OrderLines.Remove(order.OrderLines.FirstOrDefault());

            Console.WriteLine("After Removal");
            foreach (OrderLine item in context.OrderLines.Local)
            {
                Console.WriteLine($"OrderLine ID: {item.OrderLineID}, " +
                            $"OrderID: {item.OrderID}");//We're not getting null here, so it's same as the Original value
                Console.WriteLine($"OrderLine ID: {item.OrderLineID}, " +
                            $"Original Value: {context.Entry(item).Property("OrderID").OriginalValue}");
                Console.WriteLine($"OrderLine ID: {item.OrderLineID}, " +
                            $"Current Value: {context.Entry(item).Property("OrderID").CurrentValue}");
                Console.WriteLine();
            }
        }
        private static void SeedData()
        {
            using (var context = new AppContext())
            {
                context.Orders.Add(new Order()
                {
                    OrderDescription = "Order1",
                    OrderLines = new List<OrderLine>()
                    {
                        new OrderLine()
                        {
                            OrderLineDescription = "OrderLine1"
                        },
                        new OrderLine()
                        {
                            OrderLineDescription = "OrderLine2"
                        }
                    }
                });
                context.SaveChanges();
            }
        }
    }

[ajcvickers]

Note for triage: the difference from EF6 here is that DbSet.Local doesn't call DetectChanges automatically.

@fiseni EF needs DetectChanges to be called to know that the change to the navigation property has been made. For example:

 order.OrderLines.Remove(order.OrderLines.FirstOrDefault());
context.ChangeTracker.DetectChanges();

[fiseni]

Thank you @ajcvickers .

I might be reasoning wrong, but I can't see the benefit of having these actions decoupled. Now we'll have to call DetectChanges anytime we want to use DbSet.Local. Most of the time, if not always, they'll be paired anyway.

[ajcvickers]

@fiseni DetectChanges can be expensive, and depending on how Local is being used it may or may not be needed.

[ajcvickers]

Triage: we will make calling .Local call DetectChanges automatically. (Unless, of course, automatic DetectChanges is switched off.)

[Prinsn]

I might be reasoning wrong, but I can't see the benefit of having these actions decoupled

I believe my 2.2 -> 3.1 code is currently suffering a performance degredation approximating x7500 by this coupling, of 24 seconds to 50 minutes, and it's all been isolated to accessing local context.

[fiseni]

That's a huge difference. Did you try disabling DetectChanges to ensure that this coupling is causing the issue?

dbContext.ChangeTracker.AutoDetectChangesEnabled = false

Weird, EF6 always kept DbSet.Local in sync and never experienced such low performances.

[fiseni]

DbSet.Local usually is utilized through ToBindingList() and ToObservableCollection(). Since, the changes where not updated automatically, the two-way databinding was not working as expected. That's the reason of raising this issue.

Of course your use case might be totally different. Now when I see the internal implementation, if you're working directly with DbSet.Local and accessing it frequently, that would be a problem.

[Prinsn]

I did, actually. Coworker figured out an extension method that made it not too major of a code change to work around it (disable, try return dbset.local, finally set change tracking to the initial state) Dropped back to within expected tolerances without further modification

…

On Wed, Jul 8, 2020, 4:22 PM Fati Iseni ***@***.***> wrote: DbSet.Local usually is utilized through ToBindingList() and ToObservableCollection(). Since, the changes where not updated automatically, the two-way databinding was not working as expected. That's the reason of raising this issue. Of course your use case might be totally different. Now when I see the internal implementation, if you're working directly with DbSet.Local and accessing it frequently, that would be a problem. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#14001 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYR7G6CURD6TTCDIQJDQT3R2TIQFANCNFSM4GF7WLDA> .