Can we remove the "deprecated" status from `human_readable_serialization` in `CollectionOptions`?

[whfuyn]

That's exactly the feature I want, for a better debugging experience and to ease the burden of users having to encode things themselves. (These reasons might not be enough to justify it, though.)

Performance is not a major concern in my case.

Without this option, I'll have to manually implement the serialization for some structs deep in a dependence. :(

Is it possible to remove this "deprecated" status? If not, is there a plan to remove this field once the bug is fixed?

/// These are the valid options for creating a [`Collection`](crate::Collection) with
/// [`Database::collection_with_options`](crate::Database::collection_with_options).
#[derive(Clone, Debug, Default, Deserialize, TypedBuilder)]
#[builder(field_defaults(default, setter(into)))]
#[serde(rename_all = "camelCase")]
#[non_exhaustive]
pub struct CollectionOptions {
    // ...

    /// Sets the [`bson::SerializerOptions::human_readable`] option for the [`Bson`]
    /// serializer. The default value is `false`.
    /// Note: Specifying `true` for this value will decrease the performance of insert
    /// operations.
    #[deprecated = "This is a workaround for a potential bug related to RUST-1687, and should \
                    not be used in new code."]
    pub human_readable_serialization: Option<bool>,
}

[whfuyn]

Mongodb error: Kind: invalid type: string "<hex-encoded bytes>", expected a bytestring
...does it respect human_readable in deserialization?

/// Deserialize an instance of type `T` from a slice of BSON bytes.
pub fn from_slice<'de, T>(bytes: &'de [u8]) -> Result<T>
where
    T: Deserialize<'de>,
{
    let mut deserializer = raw::Deserializer::new(bytes, false);
    T::deserialize(&mut deserializer)
}

This deserializer simply returns false for is_human_readable in the Deserializer trait implementation.

[whfuyn]

mongo-rust-driver/src/cursor/common.rs

Line 281 in c070269

return Poll::Ready(Some(Ok(bson::from_slice(doc.as_bytes())?)))

It's de-serialized in here.

[whfuyn]

OK, I found RUST-1763.

• Most users are not concerned with the way their data is represented in the database as long as it properly round-trips through the driver.

But data is used by different programs, drivers can differ.

• Users who do care about the format of their data in the database can write custom serialization/deserialization logic to handle the formatting themselves.

In my case, I want some binary fields in a deep-nested struct from other crates to be hex-encoded. It's not very easy to write a custom serialization/deserialization for that.

And without a human-readable in-database format, it becomes unreadable when inspected with mongosh.

Furthermore, since the human-readable format is a feature of serde, not supporting it might create inconsistency.

[isabelatkinson]

Hi @whfuyn, thank you for raising these concerns. We plan to do a 3.0 release of the driver in the next few months, and we will reconsider our decision regarding this option as a part of that release. Feel free to follow RUST-1764 for updates.

[isabelatkinson]

The human_readable_serialization option will be removed in the upcoming 3.0.0 release in favor of a HumanReadable wrapper (mongodb/bson-rust#471). Closing this out.