[CSHARP-984] The Queryable translation for Contains converts to a non working regular expression. Created: 03/Jun/14 Updated: 05/Apr/16 Resolved: 20/Jun/14 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | API |
| Affects Version/s: | 1.9 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Paul Reed | Assignee: | Robert Stam |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
windows 2013 |
||
| Description |
|
When using this form of c# code (simplified): >> var collection = MongoDataConnection.GetCollection<T>(true); The resulting mongo command is converted to: >> collection.Find( {Name:/astring/s}) which fails with Invalid flags supplied to Regex constructor 's' >> collection.Find( {Name:/astring/s}) I still get the error - if I convert this to >> collection.Find({Name:{$regex:"astring",$options:"s"}}) it works fine.. – This is a HUGE issue for us. |
| Comments |
| Comment by Robert Stam [ 20/Jun/14 ] | |||||||||||||||||||||||||||
|
We think everything is working as designed. Please feel free to reopen and we can continue the discussion if you would like or if new information comes to light. Thanks! | |||||||||||||||||||||||||||
| Comment by Paul Reed [ 13/Jun/14 ] | |||||||||||||||||||||||||||
|
Ok, ill need to double check. Let me run some tests again on Monday. Robert Stam commented on I am unable to reproduce the error you are getting. Here is the code I was using:
And here is the output of running that code:
The server is returning the expected documents and no error occurred. I can of course reproduce the error in the shell, but that is just
– | |||||||||||||||||||||||||||
| Comment by Paul Reed [ 13/Jun/14 ] | |||||||||||||||||||||||||||
|
The table in question is only 18000 docs and the server stuck at high Robert Stam commented on It has also been pointed out to me that this kind of regular – | |||||||||||||||||||||||||||
| Comment by Robert Stam [ 13/Jun/14 ] | |||||||||||||||||||||||||||
|
It has also been pointed out to me that this kind of regular expression query is always going to be CPU intensive because it can't use an index and must therefore do a full collection scan, and regular expression matching in general is CPU intensive. So perhaps the 99% CPU you were seeing is totally normal, given the query. | |||||||||||||||||||||||||||
| Comment by Robert Stam [ 13/Jun/14 ] | |||||||||||||||||||||||||||
|
I am unable to reproduce the error you are getting. Here is the code I was using:
And here is the output of running that code:
The server is returning the expected documents and no error occurred. I can of course reproduce the error in the shell, but that is just because JavaScript regular expressions don't support the "s" option:
| |||||||||||||||||||||||||||
| Comment by Paul Reed [ 13/Jun/14 ] | |||||||||||||||||||||||||||
|
When looking at the query hitting the server, it appears to hang up. I have now worked around the issue however. But certainly no data, only Robert Stam commented on Reading the documentation linked to above more carefully, it is now It seems like as long as the driver has a way to construct a proper Are you actually getting any errors from the server when running this – | |||||||||||||||||||||||||||
| Comment by Robert Stam [ 13/Jun/14 ] | |||||||||||||||||||||||||||
|
Reading the documentation linked to above more carefully, it is now unclear to me whether the alternate form is only required in the shell (to sidestep the limitation that JavaScript's native Regex implementation doesn't support the "s" flag), or whether the server requires this form as well. It seems like as long as the driver has a way to construct a proper BSON regular expression value (and the C# driver does), then it should work at the server as well. Are you actually getting any errors from the server when running this query? Or is the server returning the correct results, just that it's using 99% CPU to do so? | |||||||||||||||||||||||||||
| Comment by Robert Stam [ 13/Jun/14 ] | |||||||||||||||||||||||||||
|
The server documentation for queries with regular expressions is here: http://docs.mongodb.org/manual/reference/operator/query/regex/ According to this documentation we need to be using:
instead of
| |||||||||||||||||||||||||||
| Comment by Paul Reed [ 03/Jun/14 ] | |||||||||||||||||||||||||||
|
Well we have had the system up and running for a few months now, this method forms part of a search which again has been functional for months. So either, people just haven;t been using it (I am sure they have) or I am being stupid some how. I am pretty sure that I have not had high CPU stuck before either. I have worked a work around, but it does code bloat somewhat. I understand that the regex problem is known within mongo, I would hope that the c# driver could be adapted to work around it. Kind Regards, Paul Reed | |||||||||||||||||||||||||||
| Comment by Craig Wilson [ 03/Jun/14 ] | |||||||||||||||||||||||||||
|
Sorry you are having some trouble. We see in the docs that this is documented, so we'll definitely get this fixed. You mentioned that "this problem has only just materialised." Would you mind expanding on this? What changed that is causing this to fail now when it wasn't failing before? For now, I can provide you a work around. You can build your query using the query builders and then inject it in, or simply use the query document with Find. It would look like the below:
|