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)

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

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.