Make CREATE MATERIALIZED VIEW DDL pluggable via MaterializedViewDdlHandler

[xiangfu0]

Summary

Makes CREATE MATERIALIZED VIEW ... AS <query> DDL pluggable via a new MaterializedViewDdlHandler extension point, so downstream distributions can support materialized views that are materialized by a different engine / minion task type (e.g. a multi-stage-engine MV whose AS clause is a JOIN) without forking the DDL compiler.

OSS behavior is byte-for-byte unchanged when no alternative handler is registered: a JOIN in the AS clause is still rejected, and the MV is still routed under the built-in MaterializedViewTask.

Motivation

Today the single-source / single-stage assumption is hardcoded in DdlCompiler.compileCreateMaterializedView:

• a JOIN in the AS clause is rejected unconditionally, and
• the MV task config is always stamped under MaterializedViewTask.

A distribution that wants a richer MV (e.g. materialize the result of a JOIN through the multi-stage engine via its own minion task type) has no clean seam — it cannot reuse the DDL compile path. Because the controller validates the resulting TableConfig (running the task generator's validation) before persisting, simply "allowing the JOIN at compile" is insufficient: the handler must be able to stamp a task type whose generator can validate that definition.

What changed (pinot-sql-ddl)

• New SPI MaterializedViewDdlHandler with two methods: validateDefinedQuery(queryNode, properties) (query/join policy, run before column resolution) and applyTaskConfig(properties, definedSql, schedule, builder) (routes the MV task config and returns the task type stamped). Includes a shared static containsJoin(SqlNode) helper.
• DefaultMaterializedViewDdlHandler — preserves current behavior exactly (reject JOINs, route under MaterializedViewTask).
• MaterializedViewDdlHandlerRegistry — process-wide registry, defaults to the single-source handler; a distribution registers its handler once at controller startup (mirrors existing pluggable-component registry patterns).
• DdlCompiler.compileCreateMaterializedView delegates query validation + task routing to the registered handler, and validates MV consistency (bucketTimePeriod present) against the task type the handler stamped.
• MaterializedViewPropertyRouter.apply gains a taskType-parameterized overload so a handler can route the MV task config under an alternative task type (the no-arg form delegates with MaterializedViewTask).
• verifyDefinedSqlIsParseable now does a syntactic parse (compileToSqlNodeAndOptions) rather than full single-stage compilation (compileToPinotQuery). The slicing-bug guard only needs to confirm the extracted text is well-formed; the syntactic parse also accepts multi-stage shapes (e.g. JOINs) a handler may permit. Engine-specific validity is still enforced later by the MV analyzer / task generator for whichever task type the handler stamped. JOINs remain rejected by default (the default handler rejects them earlier, before this check).

Testing

• All existing pinot-sql-ddl tests pass (169), including DdlCompilerMaterializedViewTest (40) — default behavior (single-source, JOIN rejected, MaterializedViewTask routing) is unchanged.

Backward compatibility

No config, wire-format, or default-behavior changes. The extension point is opt-in via the registry; absent any registration, the default handler reproduces the prior code path.

🤖 Generated with Claude Code

[codecov-commenter]

Codecov Report

❌ Patch coverage is 77.19298% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.40%. Comparing base (5a6cd7b) to head (c91cccd).
⚠️ Report is 6 commits behind head on master.

Files with missing lines	Patch %	Lines
...ntroller/helix/core/PinotHelixResourceManager.java	0.00%	8 Missing ⚠️
...ddl/compile/DefaultMaterializedViewDdlHandler.java	72.72%	3 Missing ⚠️
...ot/sql/ddl/compile/MaterializedViewDdlHandler.java	87.50%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #18639      +/-   ##
============================================
+ Coverage     64.38%   64.40%   +0.01%     
- Complexity     1282     1291       +9     
============================================
  Files          3359     3364       +5     
  Lines        207825   207935     +110     
  Branches      32447    32467      +20     
============================================
+ Hits         133818   133919     +101     
- Misses        63244    63249       +5     
- Partials      10763    10767       +4     

Flag	Coverage Δ
custom-integration1	100.00% <ø> (ø)
integration	100.00% <ø> (ø)
integration1	100.00% <ø> (ø)
integration2	0.00% <ø> (ø)
java-21	64.40% <77.19%> (+0.01%)	⬆️
temurin	64.40% <77.19%> (+0.01%)	⬆️
unittests	64.40% <77.19%> (+0.01%)	⬆️
unittests1	56.80% <ø> (+0.03%)	⬆️
unittests2	37.14% <77.19%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[xiangfu0]

Found a high-signal issue; see inline comment.

[xiangfu0]

Found a high-signal issue; see inline comment.

[xiangfu0]

Opened the docs follow-up PR for this change: pinot-contrib/pinot-docs#847