Hi, Ramin & Ron +1 with the 1 hour default for materialized-table.default-freshness.full. Hourly intervals are indeed common for batch processing.
Best, Feng On Mon, Oct 13, 2025 at 7:34 PM Ron Liu <[email protected]> wrote: > Hi, Ramin > > Regarding the `materialized-table.default-freshness.full `, I think 1 hour > may be more suitable. In offline data warehouse, the hour partition is a > common case. > > Best, > Ron > > Ramin Gharib <[email protected]> 于2025年10月13日周一 19:05写道： > > > Hi all, > > > > Thanks again for the excellent feedback on FLIP-551. The discussion has > > been very helpful, and I've made some updates to the proposal based on > your > > input. > > > > I’d like to highlight three key changes: > > > > > > 1. Added Separate Default Configurations for FULL and CONTINUOUS Modes > > > > Based on Feng's feedback, I've updated the proposal to include two > separate > > configuration options: > > - materialized-table.default-freshness.continuous (default: 3 min) > > - materialized-table.default-freshness.full (default: 15 min (TBD)) > > > > This correctly handles the edge case where a user specifies REFRESH_MODE > = > > FULL without a FRESHNESS and ensures a sensible, mode-specific default is > > always applied. A new user journey has been added to the FLIP to make > this > > behavior clear. > > > > > > 2. Simplified the MaterializedTableEnricher Interface > > > > After further review of the architecture, I've simplified the > > MaterializedTableEnricher interface significantly. It now has a single > > enrich(CatalogMaterializedTable) method. > > > > This makes the design much cleaner and more atomic. The enricher now > > receives all the context it needs directly from the unresolved > > CatalogMaterializedTable object itself. As a result, the separate > > RefreshContext class is no longer necessary, simplifying the overall API. > > > > > > Cheers, > > > > Ramin > > > > On Mon, Oct 6, 2025 at 2:18 PM Ramin Gharib <[email protected]> > wrote: > > > > > Hi everyone, > > > > > > I would like to start a discussion on FLIP-551 [1], which proposes > making > > > the FRESHNESS clause optional for Materialized Tables. > > > > > > The goal is to simplify the user experience for common streaming cases > > and > > > to enable more powerful, platform-level default logic. > > > > > > The proposal achieves this by: > > > > > > 1. > > > > > > Making the FRESHNESS DDL clause optional, falling back to a sensible > > > default of 1 minute. > > > 2. > > > > > > Introducing a new, MaterializedTableEnricher interface for custom > > > logic to resolve the final Freshness and RefreshMode into the > > > ResolvedCatalogMaterializedTable when they are omitted. > > > > > > This change reduces boilerplate for users while providing a clean > > > extension point for advanced use cases. The complete architectural > > details > > > and API are in the FLIP. > > > > > > I'm looking forward to hearing your feedback. > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-551%3A+Make+FRESHNESS+Optional+for+Materialized+Tables > > > > > > Thanks, > > > > > > Ramin > > > > > >
