jayshrivastava commented on code in PR #21807:
URL: https://github.com/apache/datafusion/pull/21807#discussion_r3140854771
##########
datafusion/physical-expr/src/expressions/dynamic_filters.rs:
##########
@@ -65,6 +65,10 @@ pub struct DynamicFilterPhysicalExpr {
/// If any of the children were remapped / modified (e.g. to adjust for
projections) we need to keep track of the new children
/// so that when we update `current()` in subsequent iterations we can
re-apply the replacements.
remapped_children: Option<Vec<Arc<dyn PhysicalExpr>>>,
+ /// Unique identifier for this dynamic filter.
+ ///
+ /// Derived filters (ex. via `with_new_children`) should inherit the
expression id of the source filter.
+ expression_id: u64,
/// The source of dynamic filters.
inner: Arc<RwLock<Inner>>,
Review Comment:
> With (mostly) an outsider's perspective, it seems like the expression_id
in this case should actually literally be an id for the inner state? So as with
https://github.com/apache/datafusion/issues/21650 , it feels like this is more
like a mutable_state_id, perhaps?
We could use the Arc address of Inner, but it's a smell to rely on pointers.
The approach in this PR is randomly generate an id for Inner and ensure that
this ID propagates when new expressions are derived using the same Inner.
You make a good point though. Do you think it would be more clear if we put
the expression_id inside the `Inner` struct? I feel like that's better
--
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]
