[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:
Duplicate
is duplicated by SERVER-19781 QueryPlanner::plan() can sometimes bu... Closed
Related
related to SERVER-17648 Implement matcher for text predicates Backlog
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   

> db.foo.drop()
true
> db.createCollection("foo",{capped:true,size:1024*1024})
{ "ok" : 1 }
> db.foo.ensureIndex({a:"text"})
> db.foo.insert({a:"world"})
> db.foo.find({$text:{$search:"hello"}}) // correct, returns no results
> db.foo.find({$text:{$search:"hello"}}).addOption(2) // incorrect, returns non-matching results
{ "_id" : ObjectId("544007b9eec1b9328f503e65"), "a" : "world" }



 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: SERVER-15688 Added check for TEXT + tailable to canonical query validation
Branch: master
https://github.com/mongodb/mongo/commit/74b6136edd3415fd08bedcd8b3ad2e7215aed285

Comment by Paul Pedersen [ 20/Jan/16 ]

Hi jason,

Got it. thanks! I see that we are still facing that issue - for some
reason i thought we had moved past it. I remember discussing this problem
2 years ago. As you say, the ticket is closed by recognizing this case and
returning an error. Not much to be done.

-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:

> db.foo.find({$text:{$search:"hello"}}).addOption(2).explain().queryPlanner.winningPlan
{
	"stage" : "COLLSCAN",
	"filter" : {
		"$text" : {
			"$search" : "hello",
			"$language" : "english",
			"$caseSensitive" : false,
			"$diacriticSensitive" : false
		}
	},
	"direction" : "forward"
}
> db.foo.find({$text:{$search:"hello"}}).explain().queryPlanner.winningPlan
{
	"stage" : "TEXT",
	"indexPrefix" : {
 
	},
	"indexName" : "a_text",
	"parsedTextQuery" : {
		"terms" : [
			"hello"
		],
		"negatedTerms" : [ ],
		"phrases" : [ ],
		"negatedPhrases" : [ ]
	},
	"inputStage" : {
		"stage" : "TEXT_MATCH",
		"inputStage" : {
			"stage" : "TEXT_OR",
			"inputStage" : {
				"stage" : "IXSCAN",
				"keyPattern" : {
					"_fts" : "text",
					"_ftsx" : 1
				},
				"indexName" : "a_text",
				"isMultiKey" : false,
				"isUnique" : false,
				"isSparse" : false,
				"isPartial" : false,
				"indexVersion" : 1,
				"direction" : "backward",
				"indexBounds" : {
 
				}
			}
		}
	}
}

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:

> db.foo.find({$text:{$search:"hello"}}).hint({$natural:1})
Error: error: {
	"$err" : "Can't canonicalize query: BadValue: text and hint not allowed in same query",
	"code" : 17287
}

Comment by Paul Pedersen [ 20/Jan/16 ]

This ticket, on the other hand, is obscure. No diagnosis as yet. How on
earth does Rassi dig these things up?? He's a bug-finding-wizard.

-P

Comment by J Rassi [ 03/Jun/15 ]

Until SERVER-17648 is implemented, these queries should fail and return an error to the user.

Generated at Thu Feb 08 03:38:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.