RUST-1022 Support configuring Serializer and Deserializer to be non-human-readable
#321
Conversation
| @@ -1062,19 +1062,30 @@ impl Display for Binary { | |||
|
|
|||
| impl Binary { | |||
| pub(crate) fn from_extended_doc(doc: &Document) -> Option<Self> { | |||
There was a problem hiding this comment.
RawBinary uses is_human_readable to determine if it should serialize to extjson or a more compact form. Since the Bson based serializer/deserializer can now present itself as not-human-readable, we need to add some special handling to them for when BSON types use a different serialization output.
| } | ||
|
|
||
| /// Builder used to construct a [`DeserializerOptions`]. | ||
| pub struct DeserializerOptionsBuilder { |
There was a problem hiding this comment.
Since it was just a single option, I opted to create the builder manually rather than bringing in typed-builder.
| @@ -610,20 +610,11 @@ impl<'a> TryFrom<RawBson<'a>> for Bson { | |||
| /// A BSON binary value referencing raw bytes stored elsewhere. | |||
| #[derive(Clone, Copy, Debug, PartialEq)] | |||
| pub struct RawBinary<'a> { | |||
There was a problem hiding this comment.
I updated this type to match the regular Binary, which has all pub fields. Note that this isn't non_exhaustive (neither is Binary).
patrickfreed
requested review from
abr-egn and
isabelatkinson
and removed request for
abr-egn
| V: Visitor<'de>, | ||
| { | ||
| match self.value { | ||
| Some(Bson::ObjectId(oid)) if !self.is_human_readable() => { |
There was a problem hiding this comment.
This special-casing of ObjectId seems like it might fit better as a case in deserialize_any?
There was a problem hiding this comment.
The reason this is here is because in the deserialize implementation of ObjectId, it checks to see if the format is human readable and, if not, uses deserialize_bytes instead of deserialize_any. The deserializer then uses that as a hint that ObjectId is being deserialized. We can't do this in deserialize_any because there's no way to hint to the deserializer that an ObjectId is being deserialized as opposed to say Bson, which needs the { "$oid": <hex string> } format to know its deserializing an ObjectId.
| UUID_NEWTYPE_NAME => { | ||
| match value.serialize(self)? { | ||
| Bson::String(s) => { | ||
| // the serializer reports itself as human readable, so `Uuid` will |
There was a problem hiding this comment.
This is no longer an invariant, no?
There was a problem hiding this comment.
good catch, forgot about this. Fixed and added a test case for this.
RUST-1022
This PR introduces two new options structs that enable users to configure
SerializerandDeserializer(used into_bsonandfrom_bson) to be considered not-human-readable, just as the raw serializer/deserializer is (used into_vecandfrom_slice). As part of that, severalto_x_with_optionsfunctions were introduced.