[SERVER-10343] Regression on master with {$regex: /foo/i} Created: 26/Jul/13 Updated: 11/Jul/16 Resolved: 26/Jul/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 2.5.1 |
| Fix Version/s: | 2.5.2 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | David Glasser | Assignee: | Andrew Aldridge |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
OSX, master built at revision 6e28cfc. |
||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Participants: |
| Description |
|
On Mongo 2.4.4: > db.y.insert( {a:'foo'}) On master: > db.y.insert( {a: 'foo'}) This only happens if you use `$regex` and you put the options directly on the BSON regex. ` {a: /O/i}` and `{$regex: 'O', $options: 'i'}` have the same behavior as in 2.4. This is presumably because in `expression_parser.cpp` in `MatchExpressionParser::_parseRegexDocument`, if `$regex` points to a `RegEx`, we only look at its `regex()` and not at its `regexFlags()` too. |
| Comments |
| Comment by David Glasser [ 26/Jul/13 ] |
|
Nice! BTW, the following is NOT a regression but is mildly surprising: in both 2.4 and (now) master, if you write `{$options: 'i', $regex: /O/}` then the options are ignored, whereas with `{$regex: /O/, $options: 'i'}` the options are not ignored. (And of course specifying the `$regex` as a string works both ways, or just not using `$regex` at all.) |
| Comment by Daniel Pasette (Inactive) [ 26/Jul/13 ] |
|
Thanks for the bug report glasser. |
| Comment by auto [ 26/Jul/13 ] |
|
Author: {u'username': u'i80and', u'name': u'Andrew Aldridge', u'email': u'andrew.aldridge@10gen.com'}Message: MatchExpressionParser::_parseRegexDocument() now makes use of options embedded Signed-off-by: Ian Whalen <ian.whalen@gmail.com> |