[DRIVERS-2765] Extended JSON spec mentions nothing about generating $uuid. Created: 07/Nov/23 Updated: 07/Nov/23 |
|
| Status: | Backlog |
| Project: | Drivers |
| Component/s: | Extended JSON |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Felipe Gasper | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Driver Changes: | Needed | ||||
| Description |
SummaryThe current extended JSON spec discusses parsing of extended JSON $uuid but seems silent about generating that format. It would be advantageous for drivers to privilege that format when serializing BSON as extended JSON; thus, the spec should probably mention $uuid’s priority. MotivationWho is the affected end user?Humans who read extended JSON (e.g., log files)—support, developers, etc. How does this affect the end user?The base64 format is harder to parse. Oftentimes it’s necessary to paste it into `base64 -d | xxd` in order to get hex to compare against something else that serializes the same UUID to hex. How likely is it that this problem or use case will occur?Almost every successful mongosync log probably has this problem. I can’t speak to its prevalence elsewhere. If the problem does occur, what are the consequences and how severe are they?Minor annoyance at a log message. Is this issue urgent?Not urgent. Is this ticket required by a downstream team?No, but it may affect things that expect $binary. Is this ticket only for tests?no Acceptance CriteriaThe extended JSON spec should mention generating $uuid, e.g.:
|