mongo-rust-driver
mongo-rust-driver copied to clipboard
mongodb
Can we remove the "deprecated" status from `human_readable_serialization` in `CollectionOptions`?
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>,
}
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.
https://github.com/mongodb/mongo-rust-driver/blob/c070269592c84627db1d87f33f88ce6c8d143c34/src/cursor/common.rs#L281
It's de-serialized in here.
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.
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.
