Обходной путь для LINQ to SQL Кэширование идентификационных данных сущностей и ошибка скомпилированного запроса? - PullRequest
4 голосов
/ 15 сентября 2009

Я сталкивался с ошибкой в ​​linq to sql, где кэширование идентификаторов не работает при выполнении запросов первичного ключа внутри скомпилированного запроса.

Я написал следующий пример, чтобы продемонстрировать использование кэширования идентификаторов. Он выполняет только один вызов базы данных при первом обращении к нему, каждый раз после этого извлекает объект клиента из кэша контекста данных.

    for(int i=0; i<10; i++)
    {
        DataContext.GetTable<Customer>().Single(c=>c.Id == 1);
    }

К сожалению, когда я преобразую приведенный выше пример в скомпилированный запрос, он не может использовать кэш идентификаторов и фактически выполняет 10 обращений к базе данных.

    for(int i=0; i<10; i++)
    {
        RetrieveCustomer(DataContext, 1);
    }

    private static readonly Func<DataContext, int, Customer> RetrieveCustomer =
    CompiledQuery.Compile((DataContext context, int id) => context.GetTable<Customer>().Single(c=>c.Id == id));

Кто-нибудь еще сталкивался с этой проблемой и создал обходной путь для нее? Для серверных приложений крайне важно использовать скомпилированные запросы и кэширование идентификаторов, поэтому я надеюсь, что это проблема, с которой уже сталкивался кто-то еще!

Ответы [ 2 ]

2 голосов
/ 08 октября 2009

Похоже на ошибку - в этой области был номер.

В качестве обходного пути я бы не создавал скомпилированный запрос для такой маленькой / простой операции - реальное преимущество скомпилированного запроса - для больших запросов, которые обрабатываются в TSQL много времени.

Обновление: это ошибка, и она была решена, так как не исправит.

1 голос
/ 09 октября 2009

В итоге я использовал грязный хак, чтобы обойти это, используя отражение, чтобы вызвать закрытый метод объектов сущностей linq, называемый GetCachedEntity, для принудительного использования кэша. У меня не было времени на внедрение более чистого решения, но всем, кто интересуется этой темой, я бы порекомендовал реализовать собственный механизм кэширования для этого сценария.

...