Closed DennisMcWherter closed 7 years ago
Actually, after reviewing the FIQL spec, it looks like filtering should always be case _in_sensitive. Is that your interpretation as well? If so, I guess I should reverse my question: does RSQL support case sensitive searches?
RSQL specifies just a syntax of the query, but does not specify semantic of the operators. This is up to you. Maybe I should really write a complete RSQL specification…?
RSQL-parser allows to define custom operators in format =<ALPHA>=
. So you can create e.g. operator =like=
for case-(in)sensitive comparison.
I was thinking about adding syntax for operator “modifier”, but I’m not sure whether it’s a good idea.
BTW I didn’t know that Yahoo uses RSQL, this is awesome!
Yes! We're using it as a supported filtering dialect on top of our JSONAPI implementation (Elide). Our team is pretty determined not to reinvent the wheel whenever possible 👍
In any case, perhaps a custom operator in this case would work fine; I'm certainly not opposed to such a scheme.
I believe defining a general operator modifier syntax may prove to be difficult. At least at first glance, there is no obvious way (to me) to describe modifiers generally for all operations that could exist. At the end of the day, I wonder if this would end up looking similar to custom operators, anyway.
@jirutka did you add support for case-sensitive queries at the end?
Does RSQL have any special way to support case insensitive
like
queries? We've been usingvalue=*abc*
which works well as long as the backing store isn't collated in a case-sensitive way.