LINQ-to-SQL DataContexts have a boolean property called ObjectTracking which is used to determine whether the framework should exert the overhead necessary to remember previous states. This defaults to true and is used to determine the SQL UPDATE command to run when persisting the object.
We have a project with data that’s read-only and so we decided to turn ObjectTracking off (set to false). We figured this was a good idea since, the thinking went, it would save overhead and since we’re not persisting the data anyway (read-only) we’ll have nothing to worry about. Boy were we wrong.
All of a sudden things started breaking! Some thing. Not others. Wierd. We figured out that it had to do with relationships not being loaded – for instance, if we have Person objects that have a collection of Car objects, the collection would be empty.
Well, apparently this is to be expected. The MSDN article on DataContext.ObjectTrackingEnabled states:
If ObjectTrackingEnabled is false, DeferredLoadingEnabled is ignored and treated as false. In this case, the DataContext is read-only.
(Interestingly enough, the next line states: “If ObjectTrackingEnabled is true, DeferredLoadingEnabled is false. In this case, DataContext allows you to load an object graph by using LoadWith directives, but does not enable deferred loading.” which clearly is not the case because it would mean there’s no difference in regards to DeferredLoadingEnabled whether ObjectTrackingEnabled is true or false! What they meant to say was “If ObjectTrackingEnabled is true AND DeferredLoadingEnabled is false…”)
So, I looked at the DeferredLoadingEnabled article and sure enough:
When the code accesses one of these relationships, null is returned if the relationship is one-to-one, and an empty collection is returned if it is one-to-many. The relationships can still be filled by setting theLoadOptions property.
(In fact, this article clears up the ObjectTrackingEnabled issue above by stating “[ObjectTrackingEnabled and DeferredLoadingEnalbed are][b]oth are set to true. This is the default.”
I guess we didn’t expect that because ObjectTracking and Lazy Loading are two very different things. Just because I don’t want to track my object does not mean I don’t want to enable lazy loading! This is just one of many quirks in Linq-to-SQL.