[ 
https://issues.apache.org/jira/browse/FLINK-38532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18047025#comment-18047025
 ] 

Hongshun Wang edited comment on FLINK-38532 at 12/24/25 6:35 AM:
-----------------------------------------------------------------

This changes the number of constructor params, causing 
ResolvedCatalogMaterializedTable not compability.

[~raminqaf] would you like to fix it?


was (Author: JIRAUSER298968):
This changes the number of constructor params, causing 
ResolvedCatalogMaterializedTable not compability.

> FLIP-551: Make FRESHNESS Optional for Materialized Tables
> ---------------------------------------------------------
>
>                 Key: FLINK-38532
>                 URL: https://issues.apache.org/jira/browse/FLINK-38532
>             Project: Flink
>          Issue Type: New Feature
>          Components: Table SQL / API
>            Reporter: Ramin Gharib
>            Assignee: Ramin Gharib
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 2.2.0
>
>
> The {{FRESHNESS}} clause, as introduced in 
> [FLIP-435|https://cwiki.apache.org/confluence/display/FLINK/FLIP-435%3A+Introduce+a+New+Materialized+Table+for+Simplifying+Data+Pipelines],
>  is a mandatory part of the {{CREATE MATERIALIZED TABLE}} syntax. While this 
> forces users to be explicit about their data recency requirements, it 
> introduces friction, especially for new users and everyday use cases.
> The primary motivations for making this clause optional are:
>  # *Reduce Boilerplate:* For many users, the goal is to create a continuously 
> updating materialized table with a low-latency, "near real-time" refresh. 
> Requiring them to specify {{FRESHNESS = INTERVAL '...' SECOND/MINUTE}} in 
> every single statement is redundant for this common pattern.
>  # *Lower Barrier to Entry:* The {{FRESHNESS}} concept, while powerful, 
> currently forces new users to immediately understand the distinction between 
> {{CONTINUOUS}} and {{FULL}} refresh modes. More importantly, to choose a 
> sensible {{{}FRESHNESS{}}}, they implicitly need to understand that this 
> value becomes the job's _checkpoint interval_ in the default streaming mode.
> By providing a sensible default, we remove this requirement. A new user can 
> get a working, continuous pipeline without needing to know about the 
> underlying checkpointing mechanism upfront. They can start with a simple, 
> functional table and learn about performance tuning concepts like 
> checkpointing later, as their needs become more advanced.
>  # *Enable Platform-Level Intelligence:* A more powerful architectural 
> approach is to allow the underlying {{Catalog}} to determine the default 
> freshness, enabling "smart" catalogs that can implement context-aware logic.
> More information to be found on the FLIP: 
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-551%3A+Make+FRESHNESS+Optional+for+Materialized+Tables



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to