Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fueled as_specific_collection #31275

Merged
merged 2 commits into from
Feb 4, 2025

Conversation

antiguru
Copy link
Member

@antiguru antiguru commented Feb 3, 2025

Adds fueling to as_specific_collection by calling into flat_map instead
of as_collection. Add a flag to restore the previous behavior.

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

@antiguru antiguru requested a review from a team as a code owner February 3, 2025 09:39
@antiguru antiguru force-pushed the fueled_as_collection branch from 4711397 to 0e59c31 Compare February 3, 2025 15:45
Copy link
Contributor

@teskje teskje left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for adding the feature flag!

@@ -97,6 +98,24 @@ where
/// The expiration time for dataflows in this context. The output's frontier should never advance
/// past this frontier, except the empty frontier.
pub dataflow_expiration: Antichain<T>,
/// The flags active in this context.
pub flags: ContextFlags,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you considered just passing a ConfigSet directly? That would reduce some boilerplate when adding a new config. You could simply access it everywhere that has access to a Context, without needing to change the fields and From implement of ContextFlags. Also makes it possible to dynamically change some configuration at runtime (without recreating the dataflow), should we ever want that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great point! Changed it such that we just have a single Rc<ConfigSet> (updating doesn't require mutability), which seems better than introducing a custom struct.

Adds fueling to `as_specific_collection` by calling into `flat_map` instead
of `as_collection`. Add a flag to restore the previous behavior.

Signed-off-by: Moritz Hoffmann <[email protected]>
@antiguru antiguru force-pushed the fueled_as_collection branch from 0e59c31 to bb9691c Compare February 4, 2025 12:30
@antiguru antiguru enabled auto-merge (squash) February 4, 2025 12:56
@antiguru antiguru merged commit a1d95aa into MaterializeInc:main Feb 4, 2025
78 checks passed
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.

2 participants