[SERVER-19610] Query skips duplicate predicate Created: 27/Jul/15 Updated: 19/Aug/15 Resolved: 30/Jul/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 3.0.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Steve Ardis | Assignee: | Ramon Fernandez Marina |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL | ||||||||||||||||||||||||
| Steps To Reproduce: | Insert a document similar to this and run the query / explains outlined in the "Description".
|
||||||||||||||||||||||||
| Participants: |
| Description |
|
$size criteria is being skipped if an additional criteria with $eq is included. Given the following query:
$size:1 is being excluded from the query, as can be seen by the generated plan:
If I comment out the $eq criteria, there are no results (as would be expected) - here is it's plan:
|
| Comments |
| Comment by Ramon Fernandez Marina [ 19/Aug/15 ] | ||||||||||||||||||||||||||||||||||||||||
|
Thanks for posting a solution based on $and scardis, this is also works – and it's simpler than using aggregation Cheers, | ||||||||||||||||||||||||||||||||||||||||
| Comment by Steve Ardis [ 17/Aug/15 ] | ||||||||||||||||||||||||||||||||||||||||
|
Thank you for your response. After giving some thought to the fact that the query is actually a JSON document, your response makes complete sense. However, I believe using the "$and" operator is the correct solution (as opposed to using the aggregate function workaround). For example:
| ||||||||||||||||||||||||||||||||||||||||
| Comment by Ramon Fernandez Marina [ 30/Jul/15 ] | ||||||||||||||||||||||||||||||||||||||||
|
scardis, a colleague points out that this is expected behavior, as your query predicate contains a duplicate field (status_records.0.notes) that gets removed by the shell:
The $size predicate is indeed gone. To illustrate further, let's swap the second and third predicates:
As you can see the last predicate on a duplicate field is the one that prevails and the only one sent to the server. You may want to consider altering your schema, although if you choose to preserve it a simple alternative is to use aggregation:
Regards, | ||||||||||||||||||||||||||||||||||||||||
| Comment by Ramon Fernandez Marina [ 30/Jul/15 ] | ||||||||||||||||||||||||||||||||||||||||
|
Thanks for your report scardis. We're able to reproduce the behavior and we're investigating. |