[DOCS-15368] Add strict UUID handling to docs Created: 27/May/22 Updated: 15/May/23 Resolved: 15/May/23 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | drivers |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Ian Ager | Assignee: | Mike Woofter |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 1 year, 36 weeks, 5 days ago |
| Epic Link: | DOCSP-8754 |
| Story Points: | 2 |
| Description |
|
Hi, Sorry if this is in the wrong place for this. In https://jira.mongodb.org/browse/JAVA-3518 the default UUID representation is changed from JAVA_LEGACY to UNSPECIFIED. This is mentioned in the docs under upgrading to 4.0: I would argue that the current wording suggests if you simply set UuidRepresentation back to JAVA_LEGACY then you'd see no behaviour change from 3.12.x. However as a result of this change decoding has become stricter - 3.12.x with representation JAVA_LEGACY would still merrily decode a subtype 4 binary object as UUID: However in 4.0.x the representation MUST be STANDARD to decode subtype 4 as UUID: I understand the point of this change, I'd just like to suggest rewording the docs to be clear that this isn't a simple change of parameter default value - mixed representations of UUID in a collection will no longer be decoded leniently. A/C:
Potential Solution:Update the Upgrade Driver Version to further discuss the differences between 3.x and 4.x UUID representations. |