Revisit control of case-sensitivity for Text field GraphQL filters

[molomby]

Like most field types, Text fields add a collection of optional filters to the query condition input type for the list (eg. [key]_contains, [key]_starts_with, [key]_not, ...). In the current implementation Text field also add a [key]_case_sensitive Boolean field. This controls the case-sensitivity of most (but not all) of the filters for that field.

There are several problems with this:

1. You can't set case sensitivity per filter (without complicating the query with "ands"). Eg...

   {
   name_starts_with: 'Jo', # This should be case sensitive
   name_contains: 'hn', # This should be case insensitive
   name_case_sensitive: # ??
   }

2. It implies the flag is relevant to all filters for the field. This is current not the case for the Mongo adapter ([key]_in and [key]_not_in don't respect the flag). If we add comparison filters like [key]_gt and [key]_lt supporting this (if we even wanted to) gets harder still since it'll be fighting the natural collation supplied by the DB.
3. The default is probably wrong. The current implementation defaults to case-insensitive which..
   • Diverges from Mongo, Postgres and JS (which are case sensitive by default)
   • Diverges from the Prisma/Graphcool API (I think?)
   • Basically circumvent any indexes in Mongo (pg can index both ways if we'd like)

So, I'd like to start a discussion, the outcome of which is a spec describing how a GraphQL consumer achieves case-sensitive and case-insensitive filtering of Text fields. My suggestion is:

• Sensitive by default
• Some filters have case-insensitive alternatives, prefixed with .._case_insensitive (or maybe just .._i? Eg. { "name_contains_i": "jo" })

Also, does this apply equally to other possible/upcoming, Text-like fields? Eg. Html, Markdown, Textarea, Url, Email, TextArray, ...?

[MadeByMike]

Resolved