[JAVA-3759] BsonBinary subtype v4 (UUID Standard) gets converted back to Binary and not UUID Created: 09/Jun/20 Updated: 27/Oct/23 Resolved: 15/Jun/20 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | BSON |
| Affects Version/s: | 3.12.5 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Arushi Dhunna | Assignee: | Unassigned |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
On reading UUID subtype V4 from MongoDB using mongo-java-driver 3.12.5, BsonBinary subtype v4 (STANDARD Uuid) gets converted back to Binary and not UUID. Line of code where this bug occurs: Which throws mapping exception only in case of UUID v4 (and not in V3) : Causing: dev.morphia.mapping.MappingException: Could not map Entity with ID: org.bson.types.Binary@e1123829 As a result, calling client is forced to add a decoding hook transformer for Binary to UUID |
| Comments |
| Comment by Justin Lee [ 10/Jun/20 ] |
|
2.0.0-RC1 is out. Hopefully it will be out in the next couple of weeks. It's currently waiting on the 1.6 release to go out which is currently being evaluated. |
| Comment by Arushi Dhunna [ 10/Jun/20 ] |
|
Thank-you Justin
|
| Comment by Justin Lee [ 10/Jun/20 ] |
| Comment by Justin Lee [ 10/Jun/20 ] |
|
I'll try to play with it tonight and see what might be possible. It's ugly in there, though. That's why i rewrote it. |
| Comment by Justin Lee [ 10/Jun/20 ] |
|
2.0 has an option to specify the UUID representation but 1.x does not. We simply take the client we're given and use that. 2.0 will also use the client as is. I'm not entirely comfortable overriding values potentially set by the user in those cases. Serialization in 1.x is ... complicated. I don't have that code in front me right now but I'm reasonably sure it just passes the UUID in the DBObject and lets the driver manage writing that out. 2.x relies completely on codecs for that to happen so if the client is configured correctly it should "Just Work."
|
| Comment by Arushi Dhunna [ 10/Jun/20 ] |
|
@Jeffrey Okay. I created PR thinking that if type 3 is getting converted into UUID, then type 4 also should. |
| Comment by Jeffrey Yemin [ 10/Jun/20 ] |
|
Hi adhunna@expedia.com, thanks for the PR. The problem is that it's an application-visible behavioral change. While it's correct for your application, it may change expectations for other users who are expecting the current behavior. jlee@antwerkz.com it seems like this could be fixed at the mapping layer in Morphia though without introducing a backwards breaking change. Morphia is in a position to know that a UUID is expected, and could translate a type 4 BsonBInary to a UUID when decoding into a POJO with a UUID field. What do you think? |
| Comment by Arushi Dhunna [ 10/Jun/20 ] |
|
Hi Jeffrey, I happened to create this PR : https://github.com/mongodb/mongo-java-driver/pull/552 |
| Comment by Justin Lee [ 10/Jun/20 ] |
|
Correct. As of 2.0, we're completely on MongoCollection. If a user only passes the host and database name for Morphia to automatically create the com.mongodb.client.MongoClient and configure the UUID representation using the STANDARD value. 1.x users are responsible for creating their own clients and so will need to set it correctly. |
| Comment by Jeffrey Yemin [ 10/Jun/20 ] |
|
Is this a regression, or are you seeing this with previous releases as well? From initial investigation it appears that the behavior hasn't changed. justin.lee, do you think this will continue to be a problem in later versions of Morphia? The class in question is only used by the DB/DBCollection legacy API, and my understanding is that later versions of Morphia no longer rely on that API.
|