Skip to content

[FLINK-41209][table] Run materialized table jobs in any TableEnvironment - #29659

Open
Timm0 wants to merge 4 commits into
apache:masterfrom
Timm0:FLINK-41209
Open

Timm0 wants to merge 4 commits into
apache:masterfrom
Timm0:FLINK-41209

Conversation

@Timm0

@Timm0 Timm0 commented Oct 28, 2026

Copy link
Copy Markdown
Contributor

What is the purpose of the change

Materialized table refresh jobs could only be managed by the SQL Gateway, because MaterializedTableManager lived there. On a plain TableEnvironment, CREATE MATERIALIZED TABLE only wrote the catalog without starting a refresh job, DROP left the job running, and SUSPEND, RESUME and REFRESH threw. This change moves that logic into the planner as DefaultMaterializedTableExecutor, which every TableEnvironment uses, including the one inside the SQL Gateway.

Brief change log

  • DefaultMaterializedTableExecutor replaces MaterializedTableManager andTableEnvironmentImpl#executeInternal routes every MaterializedTableOperation to it
  • Job submission is behind the new MaterializedTableJobSubmitter SPI:
    • DefaultMaterializedTableJobSubmitter serves plain environments
    • GatewayMaterializedTableJobSubmitter serves the SQL Gateway
    • RefreshJobTarget verifies execution targets
  • New JobRetrievalSupportedPipelineExecutor, implemented by AbstractSessionClusterExecutor
  • The SQL Gateway delegates materialized table operations and REST refresh to the shared executor
  • Add MaterializedTableTableApiITCase, a Table API mirror of MaterializedTableStatementITCase
  • Add DefaultMaterializedTableExecutorTest, which replaces MaterializedTableManagerTest
  • Add RefreshJobControllerTest unit tests for RefreshJobController
  • Add MaterializedTableExecutorFactory discovery check in LoaderITCase
  • Document Table API usage

Verifying this change

  • Add MaterializedTableTableApiITCase, a Table API mirror of MaterializedTableStatementITCase
  • Add DefaultMaterializedTableExecutorTest, which replaces MaterializedTableManagerTest
  • Add RefreshJobControllerTest unit tests for RefreshJobController
  • Add MaterializedTableExecutorFactory discovery check in LoaderITCase
  • Existing MaterializedTableStatementITCase report green and show no behavior change for materialized tables from the SQL Gateway, apart from some exception types

Does this pull request potentially affect one of the following parts:

  • Dependencies (does it add or upgrade a dependency): no
  • The public API, i.e., is any changed class annotated with @Public(Evolving): no
  • The serializers: no
  • The runtime per-record code paths (performance sensitive): no
  • Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
  • The S3 file system connector: no

Documentation

  • Does this pull request introduce a new feature? yes
  • If yes, how is the feature documented? docs

Was generative AI tooling used to co-author this PR?
  • Yes (please specify the tool below)

Generated-by: Claude Code Opus 5.5

@Timm0
Timm0 marked this pull request as ready for review October 28, 2026 16:27
@flinkbot

flinkbot commented Oct 28, 2026 •

Copy link
Copy Markdown
Collaborator

CI report:

Bot commands The @flinkbot bot supports the following commands:
  • @flinkbot run azure re-run the last Azure build

@raminqaf raminqaf self-assigned this Oct 29, 2026
Timm0 added 4 commits October 29, 2026 08:55
- Add `JobRetrievalSupportedPipelineExecutor` to `flink-core`: a `PipelineExecutor` that returns a `JobClient` for a job it did not submit
- Implement it in `AbstractSessionClusterExecutor`, so remote, YARN and Kubernetes session clusters support it
…refresh jobs

- Add `RefreshJobTarget` (execution target and cluster id of a refresh job, with the checks for new and restarted jobs) and `RefreshJobResult`
- Add `RefreshJobController`, which gets the status of, cancels and stops refresh jobs with a savepoint through the recorded target's `JobRetrievalSupportedPipelineExecutor`
- Add `RefreshJobControllerTest` and `TestingJobClient`
- Add the `MaterializedTableExecutor`, `MaterializedTableExecutorFactory`, `MaterializedTableJobSubmitter` and `RefreshWorkflowContext` SPI
- Move the SQL Gateway's `MaterializedTableManager` into the planner as `DefaultMaterializedTableExecutor`; `TableEnvironmentImpl` and the bridges look up its factory, also through the planner loader
- Route `MaterializedTableOperation`s to the executor when the environment has a job submitter
- Run the SQL Gateway's materialized table operations and REST refresh through the executor with `GatewayMaterializedTableJobSubmitter`; root causes are now `TableException`s
- Replace `MaterializedTableManagerTest` with `DefaultMaterializedTableExecutorTest`
- Add `DefaultMaterializedTableJobSubmitter`, which submits refresh jobs from a plain `TableEnvironment` to session clusters
- Route materialized table operations of every `TableEnvironment` to the executor
- Add `MaterializedTableTableApiITCase`; `ExplainTest` writes its materialized tables to the catalog directly
- Document Table API usage and fix `execution.mode` to `execution.target` in the deployment docs
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.

3 participants