[SERVER-7985] $or within findAndModify with a mongos should correctly check if all expressions in one shard Created: 19/Dec/12  Updated: 06/Dec/22  Resolved: 19/Apr/18

Status: Closed
Project: Core Server
Component/s: Querying, Sharding
Affects Version/s: 2.2.2
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Matt Kalan Assignee: Backlog - Query Team (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-30225 Sharded writes should extract shard k... Backlog
Assigned Teams:
Query
Operating System: ALL
Steps To Reproduce:

This fails
db.responses.update({
"$or":[

{"itemId":24, "importDocumentId" : "90016201230095201111"}

,

{"itemId":24, "importDocumentId" : "90016201230085201111"}

]},
{$set:{responseStateCode:2}});
can't do non-multi update with query that doesn't have a valid shard key

This works
db.responses.update({
"itemId":{$in:[24,25]},
"importDocumentId":{$in:["90016201230095201111", "90016201230085201111"]}},
{$set:{responseStateCode:2}});

-------------FindAndModify--------------

This fails
db.responses.findAndModify({
query:{"$or":[

{"itemId":24, "importDocumentId" : "90016201230095201111"}

,

{"itemId":24, "importDocumentId" : "90016201230085201111"}

]},
update : {$set:

{responseStateCode:2}

}});
Thu Dec 13 16:12:32 uncaught exception: findAndModifyFailed failed: "db assertion failure"

This works
db.responses.findAndModify({
query:{
"itemId":{$in:[24,25]},
"importDocumentId":{$in:["90016201230095201111", "90016201230085201111"]}},
update : {$set:

{responseStateCode:2}

}});

Participants:

 Description   

Currently doing an $or([

{key1: A1,key2: B1}

,

{key1:A2,key2:B2}

,...] fails in a sharded cluster because it does not first check if the values given are on the same shard, whereas $in does check. They should be consistent and do the best to implement findAndModify within one shard. The below steps to reproduce shows the differences.



 Comments   
Comment by David Storch [ 19/Apr/18 ]

Agreed that this belongs with the query team. The limitation described here still exists. I'm marking this as a duplicate of a more recent ticket, SERVER-30225, since the newer ticket has additional details and more watchers.

Comment by Gregory McKeon (Inactive) [ 19/Apr/18 ]

Found this as part of sharding reviewing old tickets - we believe this is a query issue.

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