Построение странного запроса в linq to db, как исправить?

Question

[Михаил]

Linq to DB

return await dbSet.FirstOrDefaultAsync(u => u.Email.ToUpper() == email.ToUpper());

Превращается в

FROM [dbo].[Users] AS [Extent1]
    WHERE ((UPPER([Extent1].[Email])) = (UPPER(@p__linq__0))) OR ((UPPER([Extent1].[Email]) IS NULL) AND (UPPER(@p__linq__0) IS NULL))

Как убрать or?

Answer 1

[Алексей Немиро]

По умолчанию чувствительности к регистру быть не должно и если это не было сделано намерено, то нет необходимости делать ToUpper().

return await dbSet.FirstOrDefaultAsync(u => u.Email == email);

Comments

[Станислав Силин]

И как это поможет решить на поставленый вопрос?

[Алексей Немиро]

Станислав Силин: если нет проблемы, то нет смысла её создавать и решать :-)

Если чувствительность к регистру не была сделана намеренно, то манипуляции с регистром - это лишняя операция, который быть не должно.

[Михаил]

простите но где нет чуствительности к регистру по умолчанию?

[Алексей Немиро]

Михаил: на уровне базы. За это отвечают параметры сортировки. Если имя параметра сортировки содержит _CI, то это case-insensitive, без учета регистра (по умолчанию).

Выписка из MSDN для SQL Server 2016:

Параметр	Описание
С учетом регистра (_CS)	Различаются буквы верхнего и нижнего регистров. При выборе этого параметра буквы нижнего регистра при сортировке ставятся перед соответствующими буквами верхнего регистра. Если этот параметр не установлен, параметры сортировки не будут учитывать регистр. То есть при сортировке SQL Server считает буквы верхнего и нижнего регистров идентичными друг другу. Можно явно выбрать нечувствительность к регистру, указав параметр _CI.
С учетом диакритических знаков (_AS)	Различаются символы с диакритическими знаками и без них. Например, "a" отлично от "ấ". Если этот параметр не установлен, параметры сортировки не будут учитывать диакритические знаки. То есть, при сортировке SQL Server считает буквы с диакритическими знаками и без них идентичными друг другу. Можно явно выбрать нечувствительность к диакритическим знакам, указав параметр _АI.
С учетом типа японской азбуки (_KS)	Различаются два вида японской азбуки: хирагана и катакана. Если данный параметр не выбран, параметр сортировки не чувствителен к типу японской азбуки. То есть, при сортировке SQL Server рассматривает символы хирагана и катакана как идентичные. Пропуск этого параметра является единственным способом указания нечувствительности к типу японской азбуки.
С учетом ширины символов (_WS)	Отличия между символами полной ширины и средней ширины. Если данный параметр не выбран, SQL Server принимает отображение одного и того же символа полной ширины и средней ширины для целей сортировки как идентичное. Пропуск этого параметра является единственным способом указания нечувствительности к ширине символов.

[Алексей Немиро]

Михаил: Добавлю, что без лишний преобразований, на выходе будет что-то типа:

FROM [dbo].[Users] AS [Extent1] WHERE [Extent1].[Email] = @p__linq__0

Проверка на IS NULL тоже может быть, если на уровне базы и/или при сопоставлении для поля Email разрешено значение NULL, тут уже вам виднее, нужно это или нет.

[Михаил]

Алексей Немиро:
select case when 'up' = 'up' then 1 else 0 end
,case when 'up' = 'Up' then 1 else 0 end
,case when 'up' = 'up ' then 1 else 0 end

1 0 1 отвечает мне ms sql 12.0.2000

[Алексей Немиро]

Михаил: значит параметры сортировки так настроены. Обычно регистр не учитывают, слишком много геморроя с этим будет. Cyrillic_General_CI_AS используется по умолчанию в русскоязычной среде, если намеренно не менять (например, при установке SQL Server или добавлении базы, или для отдельных полей). Не припомню, когда последний раз мне в веб требовалась чувствительность к регистру, а вот кривая конфигурация SQL Server, в частности параметры сортировки, доставляют массу неудобств.

Параметры сортировки можно указать и в запросе:

select
case when 'up' = 'up' then 1 else 0 end,
case when 'up' = 'Up' COLLATE Latin1_General_CI_AS then 1 else 0 end,
case when 'up' = 'up ' then 1 else 0 end

Но лучше настроить базу, проще будет жить :-)