[GODRIVER-695] "lax" mode for BSON decoding like mgo/bson Created: 13/Dec/18  Updated: 13/Jan/20  Resolved: 13/Jan/20

Status: Closed
Project: Go Driver
Component/s: BSON
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor - P4
Reporter: David Golden Assignee: Isabella Siu (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GODRIVER-1216 mgo compatible bson registry Closed
Epic Link: MGO BSON compatibility

 Description   

In porting mongotop to the new driver, I discovered a subtle incompatibility.  The top command returns a document like this:

{
        "totals" : {
                "note" : "all times in microseconds",
                "admin.system.roles" : { ... },
                "admin.system.version" : { ... },
                ...
        }
}

mongotop wants to decode that into a type like this:

type Top struct {
    Totals map[string]NSTopInfo `bson:"totals"`
}

The problem is that the 'note' field is a string, not a document, so can't be decoded to a "NSTopInfo" struct. mgo's Unmarshal behavior is: "if the value would not fit the type and cannot be converted, it's silently skipped", so with mgo, the 'note' field was ignored.

The Go driver is strict – and errors on the 'note' field. On the one hand, this is correct behavior, but on the other hand it may cause surprising and subtle user pain converting from mgo where irregular structures like the 'top' output could be handled more seamlessly.

I have no strong feelings one way or another, but thought there should be some discussion of whether/how to address or avoid this user pain.



 Comments   
Comment by Isabella Siu (Inactive) [ 13/Jan/20 ]

After revisiting this for the mgo bson compatibility epic, we have decided not to do this. We don't want to support silently skipping values, as it could lead to users losing data.  Users who are unsure what type they are receiving should decode into an interface{} instead.

Comment by Ian Whalen (Inactive) [ 07/Jan/19 ]

No plans to do anything about this for now because, as stated in the ticket, we do believe we now have the correct behavior, but will leave this open to centralize community interest in case we want to do this later.

Generated at Thu Feb 08 08:34:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.