adriangb commented on code in PR #24628: URL: https://github.com/apache/datafusion/pull/24628#discussion_r4318247568
########## datafusion/physical-expr/src/proto.rs: ########## @@ -0,0 +1,238 @@ +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +//! The `PhysicalExpr` face of the session-scoped [`ProtoDecoderRegistry`], +//! which routes extension expressions to their decoders by name: +//! [`register_physical_expr`] and [`physical_expr_names`], all keyed on `dyn PhysicalExpr`. The store itself +//! is shared with every other extension kind, so a session carries one +//! registry. + +use std::sync::Arc; + +use datafusion_common::Result; +use datafusion_physical_expr_common::physical_expr::PhysicalExpr; +pub use datafusion_physical_expr_common::physical_expr::proto_decode::PhysicalExprDecodeCtx; +pub use datafusion_physical_expr_common::physical_expr::proto_encode::PhysicalExprEncodeCtx; +pub use datafusion_proto_models::ProtoDecoderRegistry; +use datafusion_proto_models::protobuf::PhysicalExprNode; +use datafusion_proto_models::protobuf::physical_expr_node::ExprType; + +/// The wire name of an extension [`PhysicalExpr`], and the constructor that +/// rebuilds it. +/// +/// Only extension expressions implement this. A built-in expression has an +/// `ExprType` variant of its own, keeps the inherent `try_from_proto` +/// dispatched from that variant, and has no wire name to be registered under — +/// so [`register_physical_expr`] will not accept one. +/// +/// One impl block says what the expression is called and how it decodes; its +/// `try_to_proto` on [`PhysicalExpr`] writes the matching node with +/// [`extension_expr_node`]: +/// +/// ```ignore +/// impl PhysicalExpr for MyExpr { +/// // ... +/// fn try_to_proto( +/// &self, +/// ctx: &PhysicalExprEncodeCtx<'_>, +/// ) -> Result<Option<PhysicalExprNode>> { +/// // Stamps `Self::NAME`, so the encoded name and the registry key +/// // cannot drift apart. +/// Ok(Some(extension_expr_node::<Self>( +/// ctx, +/// self.state.to_bytes()?, +/// self.children(), +/// )?)) +/// } +/// } +/// +/// impl ExtensionExprFromProto for MyExpr { +/// // Namespace the name with the owning crate, so a collision with +/// // another crate is an error at registration and not a wrong decode. +/// const NAME: &'static str = "my_crate.MyExpr"; +/// +/// fn try_from_proto( +/// node: &PhysicalExprNode, +/// ctx: &PhysicalExprDecodeCtx<'_>, +/// ) -> Result<Arc<dyn PhysicalExpr>> { +/// let extension = expect_expr_variant!( +/// node, +/// physical_expr_node::ExprType::Extension, +/// "Extension", +/// ); +/// let state = MyState::from_bytes(&extension.expr)?; +/// let children = ctx.decode_children_expressions(&extension.inputs)?; +/// Ok(Arc::new(MyExpr::new(state, children))) +/// } +/// } +/// +/// let mut registry = ProtoDecoderRegistry::new(); +/// register_physical_expr::<MyExpr>(&mut registry)?; +/// let config = SessionConfig::new().with_extension(Arc::new(registry)); +/// ``` +pub trait ExtensionExprFromProto: PhysicalExpr + Sized { + /// The name this expression type is written and registered under. + /// + /// Namespace it with the owning crate — `"my_crate.MyExpr"`, not + /// `"MyExpr"` — so that two independent crates registering into the same + /// session collide at registration time instead of silently decoding each + /// other's nodes. Never write it by hand on the wire: + /// [`extension_expr_node`] stamps it for you. + const NAME: &'static str; + + /// Rebuild the expression from the `PhysicalExprNode` its + /// [`PhysicalExpr::try_to_proto`] wrote. + /// + /// Takes the whole node — the exact inverse of what `try_to_proto` + /// returns — so the constructor can also see outer-node fields such as + /// `expr_id`. `ctx.session::<TaskContext>()` gives the session, for + /// resolving UDFs by name or reading configuration. + fn try_from_proto( + node: &PhysicalExprNode, + ctx: &PhysicalExprDecodeCtx<'_>, + ) -> Result<Arc<dyn PhysicalExpr>>; +} + +/// Build the `PhysicalExprNode` for an extension expression `T`: an +/// `Extension` variant carrying `payload`, the encoded `children`, and `T`'s +/// [`NAME`](ExtensionExprFromProto::NAME). +/// +/// The one supported way for an extension expression to write itself. It is a +/// free function rather than a method on [`PhysicalExprEncodeCtx`] because the +/// context lives in `datafusion-physical-expr-common`, below the crate that +/// can name [`ExtensionExprFromProto`]. +pub fn extension_expr_node<T: ExtensionExprFromProto>( + ctx: &PhysicalExprEncodeCtx<'_>, + payload: Vec<u8>, + children: Vec<&Arc<dyn PhysicalExpr>>, +) -> Result<PhysicalExprNode> { + Ok(PhysicalExprNode { + expr_type: Some(ExprType::Extension( + datafusion_proto_models::protobuf::PhysicalExtensionExprNode { + expr: payload, + inputs: ctx.encode_children_expressions(children)?, + expr_name: Some(T::NAME.to_string()), + }, + )), + ..Default::default() Review Comment: Good catch. Fixed in [5dc260a](https://github.com/apache/datafusion/pull/24628/commits/5dc260aff9395d4a3c2745c91fc64a1e46b43c17). The serialized now sets `expression_id()` on any node from a hook that leaves `expr_id` empty. I added a test for deduping by id. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
