[SERVER-27557] $or and $and in aggregate's $match seem not to work correctly Created: 30/Dec/16 Updated: 10/Mar/23 Resolved: 02/Jan/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | 3.4.0, 3.4.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Michael Rommel | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Operating System: | ALL |
| Steps To Reproduce: | sh ./import.sh |
| Sprint: | Query 2017-01-23 |
| Participants: |
| Description |
|
The use of four filters in a $match clause include documents, which should be omitted. Unless I have made a stupid mistake, all four match filters should be implicitly "$and"'ed together, however the two "$or" clauses seem to cause a conflict, although they are on different fields. I reproduced this on Ubuntu Linux 16.4 with 3.4.1 and on Mac OS X El Capitan with 3.4.0
There are two arrays of values, which define interesting documents that should be included and are given as criteria for the first {{ $or }} filter step. Test data:
The output shows that "Service B3" documents are included but they are not desired and not included in the b_types array:
|
| Comments |
| Comment by David Storch [ 03/Jan/17 ] | |||||||||||||||||||||||||||
|
Hi michaelrommel, you're welcome. We've closed the ticket. Best, | |||||||||||||||||||||||||||
| Comment by Michael Rommel [ 31/Dec/16 ] | |||||||||||||||||||||||||||
|
Hi @david.storch - yes you are completely right! I did not view the argument as a JS object, but that makes sense. It also makes sense, that my last comment works, because then you can encapsulate the $or into sub-documents. Thank you, you can close the issue, I think I cannot do that myself. Thank you for the quick reaction, this issue was hard for me to track down yesterday. Once I narrowed it down to the $or, the workaround (=the actual solution) was then easier to come up with, than to debug this on a collection with 175Mio entries... Happy New Year! | |||||||||||||||||||||||||||
| Comment by David Storch [ 30/Dec/16 ] | |||||||||||||||||||||||||||
|
Hi michaelrommel, I haven't given this a careful look yet, but I did notice that the repro script has a JavaScript object with two attribute names both called $or. JS does not allow duplicate attribute names, so the second will overwrite the first. The server is probably not receiving the first $or clause:
Does this explain the behavior you're observing? | |||||||||||||||||||||||||||
| Comment by Michael Rommel [ 30/Dec/16 ] | |||||||||||||||||||||||||||
|
This also works, but not the implicit "$and"ing that should occur.
| |||||||||||||||||||||||||||
| Comment by Michael Rommel [ 30/Dec/16 ] | |||||||||||||||||||||||||||
|
Rewriting the filter this way solves the problem:
|