github-actions[bot] commented on code in PR #66287:
URL: https://github.com/apache/doris/pull/66287#discussion_r3781088071
##########
fe/fe-core/src/main/java/org/apache/doris/mtmv/MTMVRelation.java:
##########
@@ -114,4 +124,46 @@ private void compatible(CatalogMgr catalogMgr,
Set<BaseTableInfo> infos) throws
baseTableInfo.compatible(catalogMgr);
}
}
+
+ private void addStreamBaseTables(CatalogMgr catalogMgr, Set<BaseTableInfo>
infos) throws Exception {
+ if (CollectionUtils.isEmpty(infos)) {
+ return;
+ }
+ // Older images may contain only the stream relation; add its stable
base so freshness and invalidation survive
+ // an upgrade without inventing a historical snapshot for the newly
discovered dependency.
+ for (BaseTableInfo info : new HashSet<>(infos)) {
+ if (!info.isInternalTable()) {
+ continue;
+ }
+
+ // Recovery does not rerun MTMV compatibility, so an unresolved
relation must not complete migration.
+ TableIf currentTable = MTMVUtil.getTable(info);
+ addStreamBaseTable(infos, info, currentTable);
+
+ // MTMV relations are name-based, but a same-name replacement must
not hide the historical stream whose
+ // stable base was omitted from an older image.
+ TableIf stableTable =
catalogMgr.getInternalCatalog().getDb(info.getDbId())
+ .flatMap(db ->
db.getTable(info.getTableId())).orElse(null);
+ if (stableTable == null) {
+ stableTable =
Env.getCurrentRecycleBin().getRecycledTableNullable(
+ info.getDbId(), info.getTableId());
+ }
+ if (stableTable != null && stableTable != currentTable) {
Review Comment:
**[P1] Reject a same-name View before accepting the stable stream**
After a successful refresh, `M` can already contain stream `S(oldId)`,
implicit base `T`, and a matching snapshot for `T`. Recoverably drop `S` and
create a same-schema View also named `S` over unrelated `B`. On the next image
load, current-name lookup returns that View and stable-ID lookup finds recycled
`S`, so this branch only re-adds the already-present `T` and compatibility
leaves `M` NORMAL. The `T` snapshot still matches, freshness treats the View as
synchronous because it is not `MTMVRelatedTableIf`, and the lazy cache reparses
`M`'s SQL through replacement `S -> B`, even though its rows came from old `S
-> T`. This can produce wrong rewrites without waiting for recycle erasure (and
the `stableTable == null` branch likewise succeeds after erasure). A different
object ID at the persisted name is an identity replacement, not a completed
dependency migration; fail compatibility/mark `SCHEMA_CHANGE` regardless of
whether old `S` is still recyclable, and add retained- and erase
d-history replacement-View tests.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
