Support case insensitive indexing
Order by returns lowercase characters before uppercase characters.
I know you can work around this by storing an all lower or all upper case version of the string you want to query by on your object but over time and scale that does add to your RU usage
Work for this feature is now planned. Will update here when work on this feature starts and when it becomes generally available.
Any updates on this issue? Small things like this one are making Cosmos DB adoption a real pain for us.
How do I get notified when this is released?
Allow for case insensitive searches with the Gremlin Step TextP.containing(string).
Optionally for the remaining text steps:
Text searches sadly are right now not that useful (atleast for us) due to different and unpredictable capital letters on some of the words we need to search for in our graph.
Unfortunately, CosmosDB is still an unfinished product. It sucks that we do not have this feature yet. How long do we need to wait?
Majid Shams commented
We have chosen Cosmos DB for our product, but now we are hitting a roadblock because of lack of case-insensitive capability. This is an absolutely required feature.
Dave Dean commented
My experience is that default asc sorting puts upper case before lower case, not the other way around as shown in the example. Either way, this is an important feature that should not have to be implemented by duplicating data and thereby incurring synchronization costs in addition to the insert costs.
I am trying to get the matched records by keyword search and I found that "containing" method is newly provided and it is the case sensitive.
I need extra effort to make different keywords with upper case, lower case, etc and doing this reaches the limit of joins, so it starts giving issues.
We need a method which does not case sensitive.
Not everything is about RU usage, this is simply bad dev experience. It's not super straightforward, when you decide you need to order by a certain field, to process all existing documents in the database so that they have the required lower-cased property. We have the ability to do that in our project thanks to our custom schema versioning solution, but without it it's not an easy task in a big database, and it's a lot easier for devs to give up on "nice to have" features.
I suspect it's difficult to implement, considering the number of optimizations in place in Azure Cosmos DB, but please revisit this soon.