[SERVER-15688] Text queries on capped collection incorrectly return non-matching results if tailable cursor requested Created: 16/Oct/14 Updated: 16/Mar/16 Resolved: 22/Feb/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying, Text Search |
| Affects Version/s: | 2.6.0 |
| Fix Version/s: | 3.3.3 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | J Rassi | Assignee: | Paul Pedersen |
| Resolution: | Done | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Sprint: | Query F (02/01/16), Query 10 (02/22/16), Query 11 (03/14/16) | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
| Comments |
| Comment by Githook User [ 22/Feb/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'PLW', u'name': u'Paul Pedersen', u'email': u'paul@10gen.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Paul Pedersen [ 20/Jan/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi jason, Got it. thanks! I see that we are still facing that issue - for some -P | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by J Rassi [ 20/Jan/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Paul: this issue is an indirect consequence of the fact that the server does not have a real text matcher (SERVER-17648). Text predicates are only supposed to be answerable using an index scan. However, there are certain request types that can force a collection scan, such as a query against a capped collection with the tailable option set. Forcing a collection scan should not be allowed if the query includes a text predicate; when this happens, the "text matcher" (TextMatchExpressionBase::matchesSingleElement()) is invoked, which simply considers all elements to match. You can use explain() to see the query plan chosen for both queries:
For now, the correct behavior for this type of query would be to return an error, similarly to how hinting a collection scan with a text predicate returns an error:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Paul Pedersen [ 20/Jan/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This ticket, on the other hand, is obscure. No diagnosis as yet. How on -P | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by J Rassi [ 03/Jun/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Until SERVER-17648 is implemented, these queries should fail and return an error to the user. |