[GODRIVER-877] FindOne() nondeterministically returns empty singleResult Created: 13/Mar/19 Updated: 27/Oct/23 Resolved: 14/Mar/19 |
|
| Status: | Closed |
| Project: | Go Driver |
| Component/s: | BSON, Core API, Error Handling |
| Affects Version/s: | 0.3.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Matthew Nolf | Assignee: | Jeffrey Yemin |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
running mongo:3.6-stretch in docker |
||
| Issue Links: |
|
||||||||
| Description |
| Comments |
| Comment by Jeffrey Yemin [ 15/Mar/19 ] | ||||
|
Hi mjb It's because in most cases in MongoDB the order of keys does not matter, so we want to take advantage of the concise syntax of Go maps where we can. For example, in the above use case it doesn't matter the order of "address.first_line" and "address.second_line". Barring your usage above, which is uncommon, the only two other cases I can think of where order is significant are
In those case, applications should use bson.D | ||||
| Comment by Matthew Boyle [ 15/Mar/19 ] | ||||
|
Hi Jeff, Also interested in this. Could you give a concrete use case for bson.M? I cannot think of one and am wondering why non-deterministic code is included in the API.
Thanks, Matt | ||||
| Comment by Jeffrey Yemin [ 14/Mar/19 ] | ||||
|
It's because Go maps are intentionally non-deterministic. See https://blog.golang.org/go-maps-in-action, the last section on Iteration Order. If you were to use bson.D instead of bson.M, you'd see deterministic behavior. | ||||
| Comment by Matthew Nolf [ 14/Mar/19 ] | ||||
|
Hi Jeff, Modifying the filter as suggested has fixed the issue I was having, and now consistently finds and decodes a document. Could you clarify why in the previous example does this lead to inconsistent behaviour - sometimes returning the document, sometimes ErrNoDocuments? Thanks very much! | ||||
| Comment by Jeffrey Yemin [ 14/Mar/19 ] | ||||
|
Hi matthewnolf, I think your query is incorrect. When you match on a BSON document like you're doing, field order matters, and extra fields matter. Instead, you should be doing something like:
|