store: make comparisons case-insensitive

[saihaj]

Recreating #3126
Closes #3116

[lutter]

I am totally fine with this change, but it is a breaking change in that the same query may now return different data.

@azf20 Are you ok with merging this?

[azf20]

Nice! cc @That3Percent. I think this depends a bit on our apiVersioning story - this is quite a significant change in query behaviour, so I think a question is if we make this part of the first graphQL Version or not?

[That3Percent]

Nice! cc @That3Percent. I think this depends a bit on our apiVersioning story - this is quite a significant change in query behaviour, so I think a question is if we make this part of the first graphQL Version or not?

This PR seems to have some problems.

For one, this will break existing dApps which were expecting the existing case-sensitive behavior. A better option I think would have been to add case-insensitive variants of these arguments, rather than to modify the existing ones.

Another concern comes quoted from the issue:

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.

Determinism is table-stakes. We must not introduce non-determinism, and we must eradicate the existing non-determinism. So, that part gets a hard no from me unless all queries using these features are errors unless the non-determinism flag is set in graph-node... which would break all the existing queries.

[azf20]

Reasonable on breaking existing dapps - @lutter @saihaj @dotansimha what do you think about introducing a new i_contains, i_starts_with option in the where, to provide specific case insensitive behaviour? My instinct is that the case-sensitivity is not what most users would expect, but I can't think of an easy way to validate if dapps are relying on it.

We are addressing the database locale issue separately: #3118

[saihaj]

@That3Percent agreed that this is a breaking change and to address it as discussed in the ticket we are adding strict filters #3117 so should we instead keep this as is and then and an insensitive filter?

[azf20]

@saihaj it seems that we agree - let's keep this as is and introduce a case insensitive filter. We can then monitor usage to try and understand if users are relying on the sensitivity

[saihaj]

@azf20 #3294