yujun777 commented on code in PR #69168:
URL: https://github.com/apache/doris/pull/69168#discussion_r4292015382
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/trees/plans/commands/info/CreateMTMVInfo.java:
##########
@@ -446,13 +459,17 @@ private void setTableInformation(ConnectContext ctx) {
this.setTableName(tableNameInfo.getTbl());
this.setCtasColumns(ctasColumns.isEmpty() ? null : ctasColumns);
this.setEngineName(CreateTableInfo.ENGINE_OLAP);
- if (isEnableIvm()) {
+ if (isEnableIvm() && !ivmAppendOnlyDupModel) {
+ // The unique-key model merges on write, which is what its row-id,
delete sign and sequence
+ // column are for.
this.setKeysType(KeysType.UNIQUE_KEYS);
if (properties == null) {
properties = Maps.newHashMap();
}
properties.put(PropertyAnalyzer.ENABLE_UNIQUE_KEY_MERGE_ON_WRITE,
"true");
} else {
+ // A non-IVM MV and an append-only detail MV are both plain DUP
tables: the detail one holds the
+ // query's own rows and only appends them, so there is nothing for
merge-on-write to do.
this.setKeysType(KeysType.DUP_KEYS);
Review Comment:
Fixed, thank you — the partition rule an MV is checked against now follows
the model the MV is built with:
```java
boolean validateAsMow = isEnableIvm() ? !ivmAppendOnlyDupModel :
isEnableMergeOnWrite();
```
instead of `isEnableIvm() || isEnableMergeOnWrite()`, so a plain DUP detail
MV is validated as the DUP
table it is while the unique-key model keeps the MOW rule.
Fixed in fc21f1e084b. Verified on a cluster with your exact case (a
row-binlog DUP source partitioned on `dt`, an MV declared
`KEY(id) PARTITION BY(dt) ... AS SELECT id, dt, v FROM t`): before, it was
rejected with
"Merge-on-Write table's partition column must be KEY column"; now it is
created, and its complete and
incremental refresh land the rows. The same layout on the unique-key model
(`ivm_force_mow = true`) is
still rejected by the MOW rule, which is also why the existing
`test_ivm_partition_unique_key` regression
suite (whose base table is merge-on-write) is unaffected.
Coverage added:
- a unit test for a partitioned detail MV whose partition column is a value
column;
- a partitioned detail MV in the append-only detail MV regression suite
(complete + incremental refresh);
- the two existing unit tests that assert the MOW rule for an IVM MV now ask
for the unique-key model
explicitly, which is what their names already say they are about.
Tests on the fixed code: `CreateMTMVCommandTest` (the affected class) 98
tests, 0 failures; the three
affected regression suites `test_ivm_append_only_dup_mv_1/2/3`, 0 failures.
--
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]