DanielCarter-stack commented on issue #10460:
URL: https://github.com/apache/seatunnel/issues/10460#issuecomment-3859106646

   <!-- code-pr-reviewer -->
   This is a well-designed feature request. I've verified that:
   
   1. **Current `ZetaUDF` interface is limited** - 
`seatunnel-transforms-v2/src/main/java/org/apache/seatunnel/transform/sql/zeta/ZetaUDF.java`
 only has `evaluate(List<Object>)` with no access to `SeaTunnelRow` metadata or 
lifecycle hooks.
   
   2. **Metadata exists but is inaccessible** - `SeaTunnelRow` 
(`seatunnel-api/src/main/java/org/apache/seatunnel/api/table/type/SeaTunnelRow.java`)
 contains `tableId` and `RowKind`, and `TableIdentifier` 
(`seatunnel-api/src/main/java/org/apache/seatunnel/api/table/catalog/TableIdentifier.java`)
 provides catalog/database/table names, but UDFs cannot reach them.
   
   3. **Invocation path has no context** - `ZetaSQLFunction.invokeFunction()` 
(`seatunnel-transforms-v2/src/main/java/org/apache/seatunnel/transform/sql/zeta/ZetaSQLFunction.java:649-652`)
 only passes args to `udf.evaluate()`.
   
   The proposed `default` method approach ensures backward compatibility. For 
the design discussion, please clarify:
   - Should `ZetaUDFContext` be thread-safe (given `SeaTunnelRow` reuse)?
   - Should `open()/close()` align with checkpoint lifecycle for fault 
tolerance?
   - Any considerations for serializable UDF state?
   
   I suggest referencing `SeaTunnelTransform.open()/close()` 
(`seatunnel-api/src/main/java/org/apache/seatunnel/api/transform/SeaTunnelTransform.java`)
 as a model for the lifecycle contract.


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