voonhous commented on code in PR #19642:
URL: https://github.com/apache/hudi/pull/19642#discussion_r3793865618


##########
hudi-trino/src/main/java/io/trino/plugin/hudi/HudiSplitSource.java:
##########
@@ -135,47 +130,32 @@ public HudiSplitSource(
                     queue.finish();
                 });
         this.splitLoaderFuture = 
splitLoaderExecutorService.schedule(splitLoader, 0, TimeUnit.MILLISECONDS);
-        this.dynamicFilter = requireNonNull(dynamicFilter, "dynamicFilter is 
null");
         this.dynamicFilteringWaitTimeoutMillis = 
dynamicFilteringWaitTimeoutMillis.toMillis();
-        this.dynamicFilterWaitStopwatch = Stopwatch.createStarted();
     }
 
     @Override

Review Comment:
   Added `testDynamicFilterEliminatesAllSplits` in 00c42eebfa51 to cover the 
`isNone()` -> `finished` early-termination (build side matches nothing; the 
probe-side split source must report finished). The existing 
`testDynamicFilterEnabled*/Disabled*` tests assert via EXPLAIN ANALYZE that 
filtering still engages and reduces probe-side input rows through the new 
`getNextBatch(maxSize, snapshot)` path. The timeout is honored by the engine 
via `getRequestedDynamicFilterWaitTimeoutMillis()`, which returns the same 
`hudi.dynamic-filtering.wait-timeout` value the old poll loop used.
   



##########
docker/trino/shim/pom.xml:
##########
@@ -153,9 +154,10 @@
             <scope>provided</scope>
         </dependency>
 
-        <!-- NOTE: unlike the upstream 482-SNAPSHOT shim, jts-core must NOT be
-             declared provided here: it is not part of the Trino 481 SPI 
surface
-             and SpiDependencyChecker rejects provided scope for it. It ships
-             inside the plugin dir at its transitive scope instead. -->
+        <dependency>
+            <groupId>org.locationtech.jts</groupId>
+            <artifactId>jts-core</artifactId>

Review Comment:
   Legit gap -- the pin-back steps in `release_guide.md` now include 
re-checking SPI-surface-coupled dependency scopes against the target release, 
with `jts-core`/482 as the worked example (00c42eebfa51). The shim's 
`SpiDependencyChecker` fails the build loudly in both directions, so a wrong 
scope cannot ship silently; and since `jts-core` is on the SPI surface for 
every release >= 482, any release branch cut from this point is on the provided 
side of that line.
   



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

Reply via email to