Hi Feng & Ron, thanks for the fast reply. I have updated the default value of materialized-table.default-freshness.full to 1 hour in the FLIP.
Best, Ramin On Mon, Oct 13, 2025 at 2:04 PM Feng Jin <[email protected]> wrote: > 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 > > > > > > > > > >
