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
|`IgnoreCase`|`findByFirstnameIgnoreCase`|`… where UPPER(x.firstname) = UPPER(?1)`
So if you use both features, you have to create two db indexes :(
I know that there are several different features which are related to ignoreCase and it seems its hard to sync them all. What about make it configurable on all different places? Because a lot of projects are already using different parts of the features and already have created db indexes. Changes w/o backwards compatibility could produce high load on db servers in production.
the issue report is also related to the latest comments in #2420 which has made the latest changes in the QueryUtils handling and there its also mentioned, that the handling is still not in sync. But like stated above I would not prefer to sync all places now. Instead make it configurable and implement a migration path with next major version e.g. (but still with full control via configuration)
The text was updated successfully, but these errors were encountered:
gbrehmer
changed the title
pageable sort ignore case and derived query feature ignoreCase are not in sync
pageable sort ignoreCase and derived query feature ignoreCase are not in sync
Jul 14, 2024
Pageable sort is using
lower
sql function (the variable name is misleading here):spring-data-jpa/spring-data-jpa/src/main/java/org/springframework/data/jpa/repository/query/QueryUtils.java
Line 757 in 2d5146a
Derived method functionality is using
upper
.spring-data-jpa/src/main/antora/modules/ROOT/pages/jpa/query-methods.adoc
Line 68 in 2d5146a
So if you use both features, you have to create two db indexes :(
I know that there are several different features which are related to
ignoreCase
and it seems its hard to sync them all. What about make it configurable on all different places? Because a lot of projects are already using different parts of the features and already have created db indexes. Changes w/o backwards compatibility could produce high load on db servers in production.the issue report is also related to the latest comments in #2420 which has made the latest changes in the
QueryUtils
handling and there its also mentioned, that the handling is still not in sync. But like stated above I would not prefer to sync all places now. Instead make it configurable and implement a migration path with next major version e.g. (but still with full control via configuration)The text was updated successfully, but these errors were encountered: