EF6 Отключить кэширование плана запроса с помощью перехватчика дерева команд

Ответ 1

Важно различать Query Plan Caching и Кэширование результатов:

Кэширование в инфраструктуре Entity

Кэширование плана запроса

При первом выполнении запроса он проходит через внутренний компилятор плана для перевода концептуального запроса в команду store (например, T-SQL, которая выполняется при запуске с SQL Server). Если кеширование плана запроса включено, при следующем выполнении запроса команда хранилища извлекается непосредственно из кеша плана запроса для выполнения, минуя компилятор плана.

Кэш плана запроса разделяется между экземплярами ObjectContext внутри тот же AppDomain. Вам не нужно удерживать объект ObjectContext экземпляр, чтобы извлечь выгоду из кэширования плана запроса.

Кэш запросов - это оптимизированный план инструкций SQL. Эти планы помогают делать запросы EF быстрее, чем "Холодные" запросы. Эти планы скрыты за пределами и конкретным контекстом.

Кэширование объектов:

По умолчанию, когда объект возвращается в результатах запроса, просто до того, как EF материализует его, ObjectContext будет проверять, является ли объект с тем же ключом уже загружен в ObjectStateManager. Если объект с теми же ключами уже присутствует, EF будет включать его в результатах запроса. Хотя EF все равно выдаст запрос против базы данных, это поведение может обойти большую часть стоимости материализуя объект несколько раз.

Другими словами, Object Caching - это мягкая форма кэширования результатов. Никакой другой вид 2-го уровня Cache доступен с Entity Framework, если вы специально его не включили. Кэширование второго уровня в платформе Entity Framework и Azure

AsNoTracking

Возвращает новый запрос, в котором возвращенные объекты не будут кэшироваться в DbContext или ObjectContext

Context.Set<Objects>().AsNoTracking();

Или вы можете отключить кэширование объектов для объекта, используя MergeOption NoTracking Опция:

Не будет изменять кеш.

context.Objects.MergeOption = MergeOption.NoTracking; 
var retrievedObj= context.Objects.Find(obj.Id);

В отличие от AppendOnly Option

Будет добавлено только новые (уникальные) строки. Это поведение по умолчанию.

это поведение по умолчанию, с которым вы боролись

Ответ 2

Вы уверены, что проблема возникает во всех запросах? В вашем примере вы использовали Find(), что, если вы используете ToList()? Проблема не происходит, не так ли?

В целях тестирования попробуйте использовать метод Where вместо Find(), я считаю, что у вас не будет проблем...

Если приведенная выше теория верна, замените Find() на Where внутри какого-то класса репозитория. Тогда вам не нужно ничего менять в коде.

Например, в вашем классе репозитория:

public YourClass Find(id)
{
    //do not use Find here 
    return context.FirstOrDefault(i => i.Id == id); //or Where(i => i.Id == id).FirstOrDefault();
}

В вашей бизнес-логике:

var user = repository.Find(id);

Документация метода Find() https://msdn.microsoft.com/en-us/library/system.data.entity.dbset.find%28v=vs.113%29.aspx говорит:

"... если сущность с указанными значениями первичного ключа существует в контексте, то она немедленно возвращается без запроса в хранилище..."

Итак, я считаю, что проблема заключается в Find(). Использование шаблона репозитория, заменив Find by Where, является самым простым обходным решением, которое я могу себе представить прямо сейчас. Или вместо замены вы можете проверить, активирован ли программный режим, а затем выбрать предпочтительный метод. Что вы думаете об этом?

Более сложным подходом является создание класса, который наследует от DbSet и переопределяет Find(), который будет слишком сложным.

ИЗМЕНИТЬ

Чтобы помочь нам понять, что происходит, создайте консольное приложение и зарегистрируйте операцию с базой данных, например:

using (var context = new BlogContext()) 
{ 
    context.Database.Log = Console.Write; 

    // Your code here... 
    // Call your query twice, with and without softdelete
}

Вставьте журнал, тогда мы точно увидим, что sql неверен или данные кэшируются.

РЕДАКТИРОВАТЬ 2

Ok... вместо добавления перехватчика в конструкторе класса конфигурации добавьте его в конструктор контекста, например:

//the dbcontext class      

 private IDbCommandTreeInterceptor softDeleteInterceptor;
 public DataContext()
       : base("YourConnection")
 {
    //add the interceptor 
    softDeleteInterceptor = new SoftDeleteInterceptor()           
      DbInterception.Add(softDeleteInterceptor);
 }

Затем внутри вашего класса контекста создайте метод, который удаляет перехватчик, например:

public void DisableSoftDelete() 
{
     DbInterception.Remove(softDeleteInterceptor);
}

Вызвать метод выше, если вы хотите отключить программный файл, context.DisableSoftDelete();

Ответ 3

Чтобы обновить softdelete, вы можете переопределить метод SaveChanges и создать фильтр, вы можете использовать dbContext.Query<T>(), который автоматически будет применять фильтр мягкого удаления с помощью генератора выражений.

Чтобы отфильтровать столбец мягкого удаления, вы можете реализовать следующий метод в своем DbContext.

public IQueryable<T> Query<T>(){

   var ds = this.Set<T>() as IQueryable<T>;

   var entityType = typeof(T);

   if(!softDeleteSupported)
        return ds;

   ParameterExpression pe = Expression.Parameter(entityType);
   Expression compare = Expression.Equals( 
          Expression.Property(pe, "SoftDeleted"),
          Expression.Constant(false));

   Expression<Func<T,bool>> filter = 
       Expression.Lambda<Func<T,bool>>(compare,pe);

   return ds.Where(filter);
}

Ответ 4

Я знаю, что этот вопрос был задан некоторое время назад, но так как ни один пост не был помечен как ответ, я поделюсь своим недавним опытом с этой проблемой. Как правильно объяснил Дэйв, "важно различать кеширование плана запросов и кеширование результатов". Здесь проблема кеширования плана запросов, потому что

Query Cache - это оптимизированный план инструкций SQL. Эти планы помогают выполнять запросы EF быстрее, чем "холодные" запросы. Эти планы кэшируются вне определенного контекста.

Таким образом, даже если вы создадите новый контекст, проблема останется. Мое решение этого очень простое. Вместо того чтобы полагаться только на Interceptor, мы можем добавить предложение Where в запрос в случае IfFetchSoftDeleted = true. При этом EF использует другой запрос и не использует неправильно кэшированный. Теперь будет вызываться перехватчик, но ShouldFetchSoftDeleted = true не позволяет вашему QueryVisitor применить фильтр IsDeleted.

Я использую шаблон репозитория, но я думаю, что концепция ясна.

public override IQueryable<TEntity> Find<TEntity>()
{
   var query = GetRepository<TEntity>().Find();

   if (!ShouldFetchSoftDeleted)
   {
     return query; // interceptor handles soft delete
   }

   query = GetRepository<TEntity>().Find();
   return Where<IDeletedInfo, TEntity>(query, x => x.IsDeleted == false || x.IsDeleted);
}