You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After the discussion of #996 (comment) (and previous comments) with @roji, that continued by email, we came to the conclusion that it would be best to throw as a default, when a StringComparison method is about to be translated, unless users have explicitly opted in to the feature.
The background is, that depending on the collations used, the scenario and the involved indices, MySQL might not be able to use indices at all and thus performance could suffer.
We will assume, that when users are explicitly opting in to the feature in the future, that they are aware of the possible consequences.
The text was updated successfully, but these errors were encountered:
@kanaday We marked it as a breaking-change, as we decided in the quite long discussion, that conformity to other providers and performance by default was more important than keeping compatibility.
However, we made the previous functionality opt-in for convenience, so that anybody who depends on the previous behavior, and doesn't want to use the new EF.Functions.Collation() syntax, can explicitly enable it again in an instant, and thereby confirming to be aware of possible performance implications.
To throw using these methods without opting in was a deliberate choice. It is the behavior that EF Core provides by default, but more importantly, if we would have just ignored the StringComparison parameter (and logged a warning), it could be quite hard for users to track the issue down, as many don't have warnings enabled in production and implicitly ignoring casings is difficult to trace.
So throwing ensures, that this otherwise subtle change does not go unnoticed and does not lead to data corruption.
As upgrading from 3.x to 5.0 is a major release change, and we try to keep compliance with SerVer2, such an upgrade is likely to contain breaking changes. So make sure when upgrading, that you check against them and test your application, before deploying it to production.
We label important breaking-changes, that might impact an application at runtime (instead of at compile time), accordingly.
After the discussion of #996 (comment) (and previous comments) with @roji, that continued by email, we came to the conclusion that it would be best to throw as a default, when a
StringComparison
method is about to be translated, unless users have explicitly opted in to the feature.The background is, that depending on the collations used, the scenario and the involved indices, MySQL might not be able to use indices at all and thus performance could suffer.
We will assume, that when users are explicitly opting in to the feature in the future, that they are aware of the possible consequences.
The text was updated successfully, but these errors were encountered: