[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: |
|
||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||
| 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: Here's the ideal output: {"err"=>"E11000 duplicate key error index: ruby-test-db.test.$foo_1 dup keys: [3, 4]", |
| 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. |