Question

I’ve got some code like this:

Activity[] GetAllActivities() {
  using (ScheduleContext ctx = new ScheduleContext())
    return ctx.Activities.AsNoTracking().ToArray();
}

The aim to have a very simple in-memory cache of some data: Activities is mapped to a db view which summarizes everything I need.

If I omit AsNoTracking the returned objects are non-deterministically corrupted: properties on the returned objects aren’t set correctly, and frequently one object’s property value is duplicated in other objects’ properties. There’s no warning or exception; neither on EF4.3.1 nor EF5rc2. Both CLR 4 and the 4.5 release candidate exhibit the same behavior.

The Activity objects are very simple; consisting solely of non-virtual properties of basic type (int, string, etc.) and have no key nor a relationship with any other entity.

Is this expected behavior? Where can I find documentation about this?

I understand that obviously change tracking cannot work once the relevant DbContext is gone, but I’m surprised the materialized properties are corrupted without warning. I’m mostly worried that I’ll forget AsNoTracking somewhere in a more complex scenario and get somewhat plausible but wrong results.

Edit: The entity looks as follows. Thanks Jonathan & Kristof; there is indeed a column that is inferred as the ID!

public class Activity
{
  public string ActivityHostKey { get; set; }
  public int ActivityDuration { get; set; }
  public int ActivityLastedChanged { get; set; }
  public string ActivityId { get; set; }//!!!
  public string ModuleHostKey { get; set; }
  public string ModuleName { get; set; }
...

Answer 1

I think “frequently one object’s property value is duplicated in other objects’ properties” and that the Activity objects “and have no key” are the key pieces of information here (no pun intended).

When importing a View (which obviously doesn’t have a primary key), EF guesses at what the primary key is. If tracking is then enabled, it uses that primary key to make sure only a single copy of each entity is created in memory. This means if you load two rows with the same values for the field EF guessed was the PK, the values for the second row will overwrite the first.

As for the data being “non-deterministically corrupted”, that’s probably because the database doesn’t guarantee the order the rows are returned in, and it’s a “last-in-wins” process in EF, so if the order of the records changes from the DB, the record that gets to keep it’s values changes too.

Try marking more columns as part of the primary key, or modifying the view (or the DefiningQuery in the EDMX) to contain a column based on the ROW_NUMBER function so you can use it as the primary key.