Skip to content

Forward destination_data_layer in graph_proxy::unfold#401

Open
olantwin wants to merge 1 commit intoFramework-R-D:mainfrom
olantwin:fix/graph-proxy-unfold-destination-layer
Open

Forward destination_data_layer in graph_proxy::unfold#401
olantwin wants to merge 1 commit intoFramework-R-D:mainfrom
olantwin:fix/graph-proxy-unfold-destination-layer

Conversation

@olantwin
Copy link
Contributor

@olantwin olantwin commented Mar 8, 2026

Playing around with different data layers I noticed that it wasn't possible to specify the destination layer for an unfold. This PR attempts to fill this gap.

Comments very welcome, as I'm just starting with Phlex it's possible or even likely that I overlooked a better way to do this.

With the PR code, a registration like follows becomes possible:

m.unfold<tw::ClusterSplitter>(
    "find_candidates",
    &tw::ClusterSplitter::has_more,
    [](tw::ClusterSplitter const& splitter, std::size_t index) {
        return splitter.emit(index);
    },
    concurrency::unlimited,
    "event_candidate")
    .input_family(product_query{
        .creator = "merge_window",
        .layer = "time_window",
        .suffix = "tw_data"})
    .experimental_when("tw_module:trigger")
    .output_products("candidate");

All the best,
Oliver

graph_proxy::unfold was missing the destination_data_layer parameter and
used create_glue(false) which produces glue<void_tag> instead of
glue<Splitter>. This meant algorithm authors could not specify the child
layer for unfold, and the Splitter template was not forwarded correctly
to glue::unfold.

This commit forwards the parameter and construct glue<Splitter>
directly, matching what framework_graph already does.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant