[DOCS-11589] upsert:true with a Dotted _id Query Created: 29/Mar/18 Updated: 30/Oct/23 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual, Server |
| Affects Version/s: | None |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Naynish Chaughule | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 1 year, 14 weeks, 2 days ago |
| Epic Link: | DOCSP-1769 |
| Description |
|
https://docs.mongodb.com/manual/reference/method/db.collection.update/#mongodb30-upsert-id According to this document the upsert does not go through because "This restriction ensures that the order of fields embedded in the _id document is well-defined and not bound to the order specified in the query" But if I slighlty modify the query as below it inserts successfully
|
| Comments |
| Comment by Education Bot [ 31/Oct/22 ] |
|
Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you! |
| Comment by Ian Whalen (Inactive) [ 13/Apr/18 ] |
|
Moved to DOCS as per above comments. |
| Comment by Asya Kamsky [ 03/Apr/18 ] |
|
Okay it looks like somewhere between 2.6 and 3.4 something changed and we do something more correct than before. In 2.6 we would just generate a new _id when match was provided as "_id.field" notation. In 3.4 we generate a document with the provided _id "subdocument" in given order. However, once the order is specified, it's preserved for future documents (which seems as correct as you can imagine, I think). We should definitely update the docs to remove that section or replace it with one that correctly describes the behavior and potential pitfalls, after verifying that the current behavior is in fact correct. |
| Comment by Asya Kamsky [ 03/Apr/18 ] |
|
This is true, the documentation does not seem to describe current behavior. What's more surprising is that the behavior docs describe as disallowed works in all versions going back to 2.6. Update was re-written in 2.6 so maybe that's when it changed? |