[SERVER-4637] E11000 (duplicate key error) should return a list of duplicate keys and _ids in insert, bulk insert, and continue_on_error inserts. Created: 06/Jan/12  Updated: 14/Apr/22

Status: Open
Project: Core Server
Component/s: Index Maintenance
Affects Version/s: 2.0.2
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Kyle Banker Assignee: Michael Gargiulo
Resolution: Unresolved Votes: 24
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by RUBY-356 Bulk insert with :continue_on_error r... Closed
Related
is related to SERVER-19281 Add index name as a separate field on... Closed
is related to SERVER-14801 duplicate key error should report fie... Closed
Participants:
Case:

 Description   

The current output is like this:

{"err"=>"E11000 duplicate key error index: ruby-test-db.test.$foo_1 dup key: { : 3 }", "code": 11000, "n": 0, "connectionId": 58, "ok": 1.0}

Three problems:
1. The duplicate key is specified as part of a string.
2. Only the latest duplicate key is given. On a bulk insert with continue_on_error, we should get a list containing all duplicate keys found.
3. If we're given only the duplicate keys, it's hard to be sure which documents were inserted. For that, we also need the _ids of the documents that were rejected.

Here's the ideal output:

{"err"=>"E11000 duplicate key error index: ruby-test-db.test.$foo_1 dup keys: [3, 4]",
"keys": [3, 4], rejected_ids: [ObjectId("4f071fbe935f46ab13686625"), ObjectId("4f071fbe935f46ab13686627")],
"code": 11000, "n": 0, "connectionId": 58, "ok": 1.0
}



 Comments   
Comment by John Lilley [ 15/Aug/17 ]

For the record, I'm after this to disambiguate optimistic locking scenarios so that I can differentiate the expected unique-key exception from some other issue.

Comment by Eli Skeggs [ 21/May/16 ]

Duplicate?

Comment by Thomas [ 18/Dec/12 ]

Perhaps if you're using SafeMode.True and you do get a duplicate key from the mongosafeexception, instead of providing the last error in the duplicate id - the error could provide the entire list of ids there.

Comment by Derick Rethans [ 21/Feb/12 ]

Maybe a better output would be to group the key value and the accompanying objectID so you can link them together?

Comment by Kyle Banker [ 06/Jan/12 ]

@scott. Yes, we'll have to account for the no _id situation. I'm sure there are a few ways to go about it.

Comment by Scott Hernandez (Inactive) [ 06/Jan/12 ]

What if there are no _id fields filled in from the client? They could be generated on the server depending on the ordering of events and that would be confusing to return, no?

Also, we should return the count of documents rejected/included/etc. if we don't.

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