morningman commented on code in PR #68919:
URL: https://github.com/apache/doris/pull/68919#discussion_r4241474982


##########
fe/fe-core/src/test/java/org/apache/doris/nereids/rules/expression/check/CheckCastTest.java:
##########
@@ -145,6 +145,58 @@ public void testCastBetweenVariantTypes() {
                 true));
     }
 
+    @Test
+    public void testCastToConnectorComputeVariantMatrix() {
+        // A connector Variant column (e.g. a Paimon VARIANT) is written 
through the V2 compute
+        // carrier, which encodes scalar, JSON and Variant values and arrays 
of them. CheckCast is the
+        // analysis-time gate of that contract in both cast modes, so an 
unsupported source is
+        // rejected at analysis instead of being handed to the BE.
+        List<DataType> supportedSources = Lists.newArrayList(

Review Comment:
   Confirmed on master: `UuidType` extends `PrimitiveType` rather than 
`CharacterType`, and `VariantType.isSupportedComputeV2CastSource` has no UUID 
branch, so a UUID source cast to the connector Variant type is rejected. The 
strict cast whitelist does allow UUID to ordinary `VARIANT`.
   
   This is outside this PR, though. The PR ports branch-4.x tests and changes 
no production code, and branch-4.x has no UUID type. On master the UUID type 
(#67627) and this predicate (#68320) both landed on 2026-09-29, independently 
of each other. I'll fix it in a separate PR: admit UUID in the predicate, add 
UUID and `ARRAY<UUID>` positive cases, and verify the write end to end on a 
Paimon `VARIANT` column.
   



##########
regression-test/suites/external_table_p0/paimon/write/test_paimon_write_pk.groovy:
##########
@@ -174,18 +174,14 @@ suite("test_paimon_write_pk", "p0,external,paimon") {
             FROM t_pk_string_bucket ORDER BY event_id"""
         assertTableEquals("t_pk_string_bucket", "ORDER BY event_id")
 
-        // FT-045: The sink may use a bucket-aware Exchange when the negotiated
-        // BE execution version supports it, or gather during rolling-upgrade
-        // compatibility. Either plan must preserve one owner per bucket.
+        // FT-045: The bucket-aware Exchange may use multiple writers, but 
every
+        // (partition, bucket) remains owned by exactly one writer.
         sql """SET parallel_pipeline_task_num = 4"""
         sql """SET enable_strict_consistency_dml = false"""
-        def writerPlan = sql """EXPLAIN SHAPE PLAN
+        qt_pk_writer_scaling_plan """EXPLAIN SHAPE PLAN

Review Comment:
   Not changing this one. The case is a line-for-line port of branch-4.2's 
FT-045: same fixture, same statements.
   
   What it guards is the plan. The `qt_pk_writer_scaling_plan` snapshot pins 
`PhysicalDistribute[DistributionSpecExternalTableSinkHashPartitioned]` under 
the sink with `parallel_pipeline_task_num = 4`, so a fallback to random or 
gather distribution changes the snapshot and fails the case.
   
   On `ORDER BY`: `EliminateSort` drops a sort directly under a 
`LogicalTableSink`, and `LogicalConnectorTableSink` extends it, so the executed 
INSERT gets the same physical plan as the EXPLAIN.
   
   Multi-bucket routing is covered elsewhere. `test_paimon_write_bucket_modes` 
writes a 4-bucket HASH_FIXED table, checks that more than one bucket is used, 
and compares the rows with Spark. `PaimonNativeRoutingGoldenTest` and the BE 
`PaimonNativeRowHashTest` pin the bucket and writer-ownership values to 
Paimon's own. This PR also adds the routable HASH_FIXED case to 
`PaimonWritePlanProviderTest` (bucket count 4, route columns, partition and 
bucket indexes). How many writers were active cannot be seen from SQL results.
   



-- 
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