[SERVER-36946] QueryPlannerTest::assertSolutionExists() should fail if bounds provided is a subset of the actual bounds Created: 30/Aug/18  Updated: 29/Oct/23  Resolved: 04/Oct/18

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.1.4

Type: Improvement Priority: Major - P3
Reporter: James Wahlin Assignee: Ian Boros
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Query 2018-10-08, Query 2018-10-22
Participants:

 Description   

Query planner unit tests will currently pass when the test provides bounds that are a subset of the actual bounds used by the planner. For instance, when performing the query {x: {$in: [1,2]}} you can provide the bounds {'x': [[1,1,true,true]]} and a test will pass where the bounds generated are really {'x': [[1,1,true,true], [2,2,true,true]]}.

While for a small number of our tests (mainly geo) it is useful to be able to provide a subset of bounds and confirm that they match, most would benefit from strict checks. We should make the default strict and allow those tests that require it to specify that only those provided are to be confirmed.



 Comments   
Comment by Githook User [ 04/Oct/18 ]

Author:

{'name': 'Ian Boros', 'email': 'ian.boros@10gen.com'}

Message: SERVER-36946 Tighter checks on bounds in query planner unit tests
Branch: master
https://github.com/mongodb/mongo/commit/e175f95a689b5ba63dbcf2af88ff6e0cfcde1a98

Comment by Ian Boros [ 19/Sep/18 ]

As part of this maybe we should also ban fields from solution stages which are meaningless. For example, if you include "bounds" in a "fetch" stage, there will be no error. E.g. someone might write:

{fetch: {node: {ixscan: {pattern: {a: 1}}}, bounds: [[...]]}}

(bounds was meant to belong to "ixscan"). This will just pass without checking the bounds of the ixscan node.

Comment by Ian Boros [ 19/Sep/18 ]

Nevermind^, we have special handling for 'MinKey' and 'MaxKey'.
https://github.com/mongodb/mongo/blob/2e2f3fdf13013d1cc0574908c4ca121fbdbdf1d1/src/mongo/db/query/query_planner_test_lib.cpp#L84-L97

Comment by Ian Boros [ 18/Sep/18 ]

There are a bunch of unit tests which check for bounds which use MinKey or MaxKey. Unfortunately, they all use the (string) 'MinKey' and 'MaxKey' rather than {$minKey/maxKey: 1}, meaning the tests check for the interval ['MinKey', 'MaxKey'] which is empty (and therefore a subset of anything) because 'i' > 'a'. Here's an example:

https://github.com/mongodb/mongo/blob/67ab3ae97432353dea52c74fcc5982ea4d4d7ae6/src/mongo/db/query/query_planner_test.cpp#L377-L380

Generated at Thu Feb 08 04:44:32 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.