[SERVER-54314] Relax field order assertions in jstests/aggregation/sources/project/project_with_expressions.js Created: 04/Feb/21 Updated: 29/Oct/23 Resolved: 18/Feb/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.9.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Anton Korshunov | Assignee: | Mihai Andrei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Steps To Reproduce: | resmoke run --suite=aggregation_sbe jstests/aggregation/sources/project/project_with_expressions.js |
| Sprint: | Query Execution 2021-02-22 |
| Participants: |
| Comments |
| Comment by Githook User [ 18/Feb/21 ] | |||||||||
|
Author: {'name': 'Mihai Andrei', 'email': 'mihai.andrei@10gen.com', 'username': 'mtandrei'}Message: | |||||||||
| Comment by Mihai Andrei [ 16/Feb/21 ] | |||||||||
|
To clarify, the issue appears to reproduce when we have a projection with a mix of inclusion and computed projections. Suppose we have the document {a: 1, b: 2} in a collection 'c' and we run the query db.c.find({}, {_id: 0, a: {$literal: 3}, b: 1}) With the classic engine enabled, we will get { b : 2, a : 3 } (the inclusion projection comes before the computed projection) and with SBE enabled, we get { a : 3, b : 2 } (the fields appear in their original order). Note that the SBE plan for the above query is as follows:
| |||||||||
| Comment by Mihai Andrei [ 11/Feb/21 ] | |||||||||
|
This test failure is the result of a divergence between the classic executor and SBE. Whereas the classic engine will apply inclusion projections before applying computed expressions (see also ProjectionNode::applyProjection), SBE will apply projections in the order that fields appear in the original document. How we decide to fix this test failure depends on how we interpret the above. If we don’t have any strong guarantees about field ordering in projection, then this isn’t a bug in SBE and the above test should be fixed using an unordered field comparator (something like assert.docEq(). If, on the other hand we want the order of fields produced by SBE to match that of the classic engine, then some more thought needs to given about how to accomplish this (I don't think it's as simple as modifying the implementation of the MakeObj stage). cc ian.boros |