Short version: don’t override .Equals in your LINQ TO SQL entities, unless you really know what “equals” means to your objects!
Long version: on my current project, we’re using LINQ to SQL for our ORM needs, and it’s been working pretty well for us so far. Pretty well, except for late last week when we realized that we weren’t properly persisting a number of records in our object graph.
We have a fairly complex object model, with some deep graphs of related objects, and have been using the .Add method to add child and grandchild objects into our “Order” object’s graph. There was one particular “Child” record that was only being created one time per order, when we expected several variations of this child, yet only the first was being saved.
Our object graphs were build correctly, SubmitChanges was doing its job, we weren’t getting any errors, and yet these records just weren’t making it to the database. After a few conversations with other people that have some LINQ to SQL experience and me trying some of the ugliest hacks I could think of, it dawned on me to try testing another theory I had – create another order-detail that looked similar to an existing order-detail.
Lo and behold, this similar order-detail also did not persist, and it was behaving like the other “exceptional” order-details – they were all in the object-graph, but not in the Insert Changes of my data-context! Once I was able to see this, I took a closer look at the order-detail partial class we had written, and there I saw an overridden .Equals implementation. Unfortunately, this .Equals was testing for property values within the order-detail to determine if a detail might match another detail instance, not testing for reference equality, which is evidently important to LINQ to SQL.
So there you have it – when working with LINQ to SQL entities, take care in how you decide to utilize the .Equals method and how you decide to override it.
