Могу ли я изменить sql, сгенерированный Entity Framework, до его выполнения?

У меня есть база данных с несколькими арендаторами, которая возвращает совершенно разное количество строк в зависимости от того, какой арендатор запрашивается. В последнее время мы столкнулись с проблемой сниффинга параметров, когда запросы Entity Framework (EF), выполняемые к одному арендатору (TenantID = 1), занимают гораздо больше времени, чем тот же запрос к другому арендатору (TenantID = 2). Я провел некоторое исследование и определил, что EF не поддерживает подсказки запросов (см. этот вопрос), которые позволили бы мне заставить запрос перекомпилировать каждый раз. Теперь мне интересно, могу ли я перехватить запрос Sql, сгенерированный EF, и вручную добавить «ВАРИАНТ (ОПТИМИЗАЦИЯ ДЛЯ НЕИЗВЕСТНО)» перед его выполнением. Это возможно? Является ли EF подключаемым, чтобы я мог изменить сгенерированный Sql до его выполнения? Есть примеры как это сделать?


sql-server entity-framework multi-tenant query-hints
person Mike    schedule 28.03.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вы пробовали обойти проблему? Вы можете заставить EF не использовать параметр, например:

var q = Context.Tenants.Where(t => t.TenantID == tenantId);

... будет использовать параметр, но:

var r = Context.Tenants.Where(t => t.TenantID == 1);

... не будет, и я готов поспорить, что:

var s = Context.Tenants.Where("it.TenantID = 1");

... тоже не будет.

person Craig Stuntz    schedule 28.03.2012
comment
Спасибо за ваше предложение. К сожалению, построение sql-запросов на лету, как вы делаете здесь (хотя и косвенно), считается плохой практикой из-за высокого риска атак с помощью sql-инъекций. Параметризованный sql — это лучший и самый простой подход для предотвращения внедрения sql в ваше приложение. - person Mike; 29.03.2012
comment
Вот почему EF по умолчанию использует параметры. Однако инъекция представляет собой риск только в том случае, если вы не дезинфицируете свои входные данные. В конкретном случае, который вы даете, разрешение только целочисленных входных данных устранит весь риск внедрения (хотя и не риск прямых ссылок на объекты, но параметры также не защитят вас от этого...). - person Craig Stuntz; 29.03.2012
comment
И если вы используете сканирование Fortify, недостаточно интеллектуально знать, что вы продезинфицировали свои входные данные перед созданием SQL. ;) - person John Kaster; 12.08.2013