LINQ Критические изменения в EF Core 3.0. Как сравнить строки, не получив предупреждения CA1308?

У меня был следующий код, который хорошо работал с EF Core 2.1:

.FirstOrDefault(a => (a.Name.Equals(b, StringComparison.InvariantCultureIgnoreCase).

(Хорошо, хорошо работает означает, что я получил правильные результаты, даже если он оценивался на стороне клиента, а я этого не знал).

Я обновился до EF Core 3.0 и не получил никаких ошибок, но этот код не давал ожидаемых результатов.

Я видел здесь решение. Я попробовал a.Name.ToLower() == b.ToLower(), но потом получил ошибку:

Error CA1304 The behavior of 'string.ToLower()' could vary based on the current user's locale settings. Replace this call in 'MyFunction(string, string)' with a call to 'string.ToLower(CultureInfo)'

Если я использую ToLower(CultureInfo.InvariantCulture), я получаю сообщение:

Error CA1308 In method 'MyFunction', replace the call to 'ToLower' with 'ToUpperInvariant'.

Если я использую ToUpperInvariant(), я получаю сообщение об ошибке (мне уже известно о критические изменения LINQ в EF Core 3.0):

The LINQ expression (... all the expression...) could not be translated. Either rewrite the query in a form that can be translated, or switch to client evaluation explicitly by inserting a call to either AsEnumerable(), AsAsyncEnumerable(), ToList(), or ToListAsync().

Итак, я отправная точка.

Есть ли способ как выполнить CA1304, так и выполнить запрос в БД, а не на стороне клиента?


person xavier    schedule 25.11.2019    source источник
comment
У вас была серьезная ошибка производительности, которая была скрыта оценкой на стороне клиента. Не используйте Equals в таком виде вообще, и предупреждение об ошибке и исчезнет. Сравнение строк в SQL контролируется сопоставлением столбцов. Индексы также создаются на основе сортировки столбцов. В большинстве случаев таблицы создаются с использованием сортировки case- in вариантов, что означает, что вам вообще не нужно изменять регистр.   -  person Panagiotis Kanavos    schedule 25.11.2019
comment
Что произошло до EF Core 3.0, так это то, что EF Core не смог сгенерировать операторы SQL из (ненужных) преобразований строк, поэтому он извлек все данные на стороне клиента без предупреждения и попытался отфильтровать их там, без каких-либо индексов. Это очень медленно   -  person Panagiotis Kanavos    schedule 25.11.2019
comment
Если Name покрывается индексом, изменив свой код на .FirstOrDefault(a => a.Name. == b), вы можете увидеть выполнение в N раз быстрее, где N - количество строк в таблице. Предыдущий код также заблокировал всю таблицу, что вредит масштабируемости.   -  person Panagiotis Kanavos    schedule 25.11.2019
comment
Почему вы вообще использовали StringComparison.InvariantCultureIgnoreCase или ToLower()? Вы использовали сортировку с учетом регистра? Почему бы вместо этого не изменить его на регистр - в?   -  person Panagiotis Kanavos    schedule 25.11.2019
comment
Что ж, я должен сказать, что на самом деле у меня был .FirstOrDefault(a => (a.Name.Equals(b))) без StringComparison.InvariantCultureIgnoreCase, и я просто добавил его пару дней назад, чтобы соответствовать требованиям CA1304. Мне просто игнорировать это предупреждение?   -  person xavier    schedule 25.11.2019
comment
Нет, вам следует использовать a.Name == b.   -  person Panagiotis Kanavos    schedule 25.11.2019
comment
МОЙ БОГ. Так просто. О_О Работает !!! Напишите ответ, я его приму. Спасибо!!!   -  person xavier    schedule 26.11.2019
comment
@PanagiotisKanavos: Думаю, мой ответ вас не уведомил. Если вы напишете свой комментарий в качестве ответа, я его приму (зачем вы пишете полезные ответы, даже если они тривиальные, в виде комментариев?: -O).   -  person xavier    schedule 28.11.2019


Ответы (1)


Решением, как прокомментировал Панайотис Канавос, было просто использовать a.Name == b. Легко, и это работает!

person xavier    schedule 16.12.2019
comment
Это исправление применимо для нечувствительности к регистру или чувствительности к регистру? - person Natheeshkumar Rangasamy; 13.01.2021
comment
Я думаю, это было нечувствительно к регистру, но я не уверен на 100% ... - person xavier; 13.01.2021
comment
Он нечувствителен к регистру и обрезает конец. - person julian.a; 13.07.2021