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]

Reply via email to