GraphQL: Add a case-insensitive filter for string containment

[lutter]

We have a filter field_contains: "something" which matches any entity whose field contains the string "something". The comparison for that is case sensitive. It would be good to also have a filter for string containment that is not case sensitive.

• Change _contains _starts_with, _ends_with functionality to be case insensitive #3116
• Add new filters for case sensitive match _contains_strict , _starts_with_strict, _ends_with_strict #3117
• Add new filters for case insensitive match _contains_insensitive , _starts_with_insensitive, _ends_with_insensitive #3293
• Mandate everything runs in some fixed locale en_US.UTF8 #3118

[orenyodfat]

any update re that @lutter
?

[lutter]

Hi @orenyodfat - I am sorry, but I haven't had time to work on this at all yet.

[remon-nashid]

A pretty important feature to have.

It's worth noting that case-insensitivity also matters for _starts_with, _ends_with and all string matching suffixes.

[morrigan]

Bumping this as well, hoping it will be added soon since the search feature is still not fully supported and this is the only similar replacement.

[azf20]

As a user I think this is how you would expect this functionality to work. @lutter what do you think about making this the default for contains and starts_with, and introduce new _contains_strict and _starts_with_strict for exact matching? That would of course introduce some query variability between versions

[lutter]

Yes, I totally agree that that is much more what users would expect. Making contains and starts_with case insensitive is a trivial change in the backend (replacing like with ilike in queries) One small wrinkle is that case-sensitivity is locale-dependent, and the response will depend on the locale in which the database is running, but that's not a new thing, we have that with ordering too. More a reminder that we need to define the locale for all these operations for the network.

[azf20]

One small wrinkle is that case-sensitivity is locale-dependent, and the response will depend on the locale in which the database is running, but that's not a new thing, we have that with ordering too. More a reminder that we need to define the locale for all these operations for the network.

This is interesting and I hadn't considered it. Is the deterministic solution here to make the locale configurable somehow (so all indexers can set the same value)?

[lutter]

This is interesting and I hadn't considered it. Is the deterministic solution here to make the locale configurable somehow (so all indexers can set the same value)?

I don't think it's something that graph-node should do. Locale can be configured easily through the environment resp. on creation of the database. We should mandate that everything runs in some fixed locale (maybe en_US.UTF8, though we'd need to look into if there are other locales that are more palatable to the non-English world) graph-node could then check on startup that its locale and the locale of the database are the expected one.