Skip to content

Draft: accounting for ignore case in sorting #2102

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

mipo256
Copy link
Contributor

@mipo256 mipo256 commented Aug 3, 2025

Closes #2101

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Aug 3, 2025

Field field = createField(entity, order);

OrderByField orderByField = OrderByField.from( //
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, Order By items accept an expression instead of being configured for case-insensitivity. Case-insensitive ordering requires some sort of normalization (upper or lower-case transformation) and that requires configuration as databases may have upper case or lower case indexes (e.g. spring-projects/spring-data-jpa#2420)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand this concern, and I agree. The case sensitivity is configured via Order#ignoreCase. I think we might consider to add a strategy interface, something like:

interface CaseSensitiveOrderExpressionMapper {

     // What is the contract here? What is the type of an argument?
     // Is it okay to just return String? Maybe we can go for Expression 
     String fromOrder(Order order);
}

This is a global strategy, we can make it a bit more fine-grained to be able to override its behavior on the method level via potentially new annotation

public @interface @OrderNormaliztion {
   
   String orderingClause();

   // Do we need an enum here? It is limiting the possible options. The alternative is to go for a String    
   enum NormalizationFunction {
         LOWER,
         UPPER
   }
}

The abstraction names etc. can vary of course, I want to communicate the overall idea.

As far as I understood this Spring Data JPA 2420 ticket, there is a need for normalization function to be configurable. So I think we can add both the annotation and the strategy interface.

What are you thoughts on this, @mp911de

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have still too little insight for a full overview. In SQL, you can use additionally collations (ORDER BY <column> COLLATE <collation>, https://learn.microsoft.com/de-de/sql/t-sql/statements/collations?view=sql-server-ver17, https://www.postgresql.org/docs/current/collation.html#ICU-TAILORING-RULES) meaning that we can use either normalization or collations.

I started in JPA introducing JpqlQueryTemplates but that seems insufficient. Collations between the JVM and the database (e.g. upper in the database, upper on the JVM) might be different yielding different results.

The simplemost approach could be to use lowercase everywhere, a more sophisticated one to use configurable normalization and the most elaborate variant would be considering collations, maybe even on a per-table (domain type) and per-column (persistent property) basis. Let's discuss this once @schauder is back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-triage An issue we've not yet triaged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support case-insensitive sorting
3 participants