Skip to content

Conversation

patrickfreed
Copy link
Contributor

RUST-1022

This PR introduces two new options structs that enable users to configure Serializer and Deserializer (used in to_bson and from_bson) to be considered not-human-readable, just as the raw serializer/deserializer is (used in to_vec and from_slice). As part of that, several to_x_with_options functions were introduced.

}

impl Binary {
pub(crate) fn from_extended_doc(doc: &Document) -> Option<Self> {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since it was just a single option, I opted to create the builder manually rather than bringing in typed-builder.


/// A BSON binary value referencing raw bytes stored elsewhere.
#[derive(Clone, Copy, Debug, PartialEq)]
pub struct RawBinary<'a> {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 patrickfreed marked this pull request as ready for review November 10, 2021 00:27
@patrickfreed patrickfreed requested review from abr-egn and isabelatkinson and removed request for abr-egn November 10, 2021 00:28
V: Visitor<'de>,
{
match self.value {
Some(Bson::ObjectId(oid)) if !self.is_human_readable() => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This special-casing of ObjectId seems like it might fit better as a case in deserialize_any?

Copy link
Contributor Author

@patrickfreed patrickfreed Nov 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is no longer an invariant, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch, forgot about this. Fixed and added a test case for this.

@patrickfreed patrickfreed merged commit e170a44 into mongodb:master Nov 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants