Det brukade vara fallet för äldre versioner av EF-kärna. Nu string.Contains är skiftlägeskänslig, och till exempel för sqlite mappas den till sqlite-funktionen `instr()' (jag vet inte för postgresql).
Om du vill jämföra strängar på ett skiftlägesokänsligt sätt har du DbFunctions för att göra jobbet.
context.Counties.Where(x => EF.Functions.Like(x.Name, $"%{keyword}%")).ToList();
UPPDATERING till @Gert:
En del av antagandet i frågan är felaktigt. string.Contains konverterar INTE till ett LIKE expression även om det brukade vara fallet i ef kärnversioner <=1.0 (tror jag).
- I SQLServer
string.containskonverterar tillCHARINDEX(), i oracle och sqlite tillinstr()som är skiftlägeskänsliga som standard OM INTE db eller kolumnkollation definieras på annat sätt (Återigen, jag vet inte för postgresql ). - I alla fall
EF.Functions.Like()konverterar till en SQLLIKEuttryck som är skiftlägesokänsligt som standard om inte db- eller kolumnsortering har definierats på annat sätt.
Så ja, allt går ner till sammanställning men - rätta mig om jag har fel - på ett sätt kan koden påverka den skiftlägeskänsliga/okänsliga sökningen beroende på vilken av ovanstående metoder du använder.
Nu kanske jag inte är helt uppdaterad men jag tror inte att EF-kärnmigreringar hanterar DB-sortering naturligt och om du inte redan har skapat tabellen manuellt kommer du att sluta med standardsorteringen (skiftlägeskänslig för sqlite och jag vet ärligt talat inte för de andra).
För att återgå till den ursprungliga frågan har du minst två alternativ för att utföra denna skiftlägesokänsliga sökning om inte tre i en framtida version:
- Ange kolumnsamlingen vid skapande med DbContext.OnModelCreating() med detta trick
- Byt ut din
string.ContainsavEF.Functions.Like() - Eller vänta på en lovande funktion som fortfarande diskuteras:
EF.Functions.Collate()funktion