tustvold commented on code in PR #3360:
URL: https://github.com/apache/arrow-rs/pull/3360#discussion_r1052473358
##########
arrow-flight/src/sql/mod.rs:
##########
@@ -111,30 +112,44 @@ prost_message_ext!(
TicketStatementQuery,
);
-/// ProstAnyExt are useful utility methods for prost_types::Any
-/// The API design is inspired by
[rust-protobuf](https://github.com/stepancheg/rust-protobuf/blob/master/protobuf/src/well_known_types_util/any.rs)
-pub trait ProstAnyExt {
- /// Check if `Any` contains a message of given type.
- fn is<M: ProstMessageExt>(&self) -> bool;
-
- /// Extract a message from this `Any`.
- ///
- /// # Returns
- ///
- /// * `Ok(None)` when message type mismatch
- /// * `Err` when parse failed
- fn unpack<M: ProstMessageExt>(&self) -> Result<Option<M>, ArrowError>;
-
- /// Pack any message into `prost_types::Any` value.
- fn pack<M: ProstMessageExt>(message: &M) -> Result<prost_types::Any,
ArrowError>;
+/// An implementation of the protobuf [`Any`] message type
+///
+/// Encoded protobuf messages are not self-describing, nor contain any
information
+/// on the schema of the encoded payload. Consequently to decode a protobuf a
client
+/// must know the exact schema of the message.
+///
+/// This presents a problem for loosely typed APIs, where the exact message
payloads
+/// are not enumerable, and therefore cannot be enumerated as variants in a
[oneof].
+///
+/// One solution is [`Any`] where the encoded payload is paired with a
`type_url`
+/// identifying the type of encoded message, and the resulting combination
encoded.
+///
+/// Clients can then decode the outer [`Any`], inspect the `type_url` and if
it is
+/// a type they recognise, proceed to decode the embedded message `value`
+///
+/// [`Any`]: https://developers.google.com/protocol-buffers/docs/proto3#any
+/// [oneof]: https://developers.google.com/protocol-buffers/docs/proto3#oneof
+#[derive(Clone, PartialEq, ::prost::Message)]
+pub struct Any {
Review Comment:
I wasn't sure about this, but given this replaces `prost_types::Any`, I
think I would rather stick with that name. I personally don't especially mind
name overloading, especially if it avoids stupidly long type names, as Rust has
a fairly good module system
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
