Add new filters for String types to enable case-insensitive filtering

[andreloeffelmann]

Is your feature request related to a problem? Please describe.
When filtering for fields of type String in queries the passed filter values are compared case-sensitive to the database values, see here.
It is common (at least for our data) that some values are stored with uppercase letters in the database.
When querying the API our users are often not aware of how the data is actually written (uppercase/lowercase) which leads to zero rows being returned by the filtering if the passed values do not match the underlying data exactly.

Describe the solution you'd like
It would be great if the existing String filters could be extended, e.g. like this:

• [fieldName]_IGNORING_CASE
• [fieldName]_STARTS_WITH_IGNORING_CASE
• [fieldName]_ENDS_WITH_IGNORING_CASE
• [fieldName]_CONTAINS_IGNORING_CASE
• [fieldName]_IN_IGNORING_CASE

Or maybe just with an abbreviation, like [fieldName]_IN_IC, I don't care too much about the actual spelling.

To be clear: the existing filters

• [fieldName]
• [fieldName]_STARTS_WITH
• [fieldName]_ENDS_WITH
• [fieldName]_CONTAINS
• [fieldName]_IN

should remain. They still make sense for some usecases.

If schema bloating is a concern here, maybe it is an idea to enable the additional case-insensitive filters by a directive or the global configuration...

Describe alternatives you've considered
We evaluated the _MATCHES filter via regex. Even if this can solve our problem, we hesitate to enable this filter because of the ReDoS attack possibilities as stated in your docs.

Additional context
This may also solve #4117

[btroop]

extending this to sorting could be great as well...since sorting usually prioritizes uppercase over lowercase

[andreloeffelmann]

Hey @darrellwarde, any plans on implementing this?
Some time has been passed since my initial post and no one ever replied.
The related ticket #4117 has been labelled with small, so I guess this should not be THAT troublesome to implement?

[darrellwarde]

Hey @darrellwarde, any plans on implementing this? Some time has been passed since my initial post and no one ever replied. The related ticket #4117 has been labelled with small, so I guess this should not be THAT troublesome to implement?

Hey @andreloeffelmann, this hasn't been implemented because with the library's current design, it will just massively blow up schema size. We're currently working on major releases where we aim to address this, and we will revisit features such as these at that point.