dybyte commented on code in PR #9642:
URL: https://github.com/apache/seatunnel/pull/9642#discussion_r2252929038


##########
docs/en/connector-v2/source/Redis.md:
##########
@@ -142,11 +142,26 @@ schema {
 
 ### key_field_name [string]
 
-Specifies the field name to store the Redis key in the output record  when 
`read_key_enabled = true`.
+Specifies the field name to store the Redis key in the output record  when 
`read_key_enabled = true` or `data_type = hash`.

Review Comment:
   > the optionRule method can used in:
   > 
   > 1. runtime validation
   > only requires single_field_name when read_key_enabled = true, as 
key_field_name is optional due to its default value.
   > In this case, we don't need set key_field_name
   > 2. configuration creation
   > e.g., in WebUI needs stricter rules:
   > when enabling read_key_enabled:
   > show key_field_name input with pre-filled default (key)
   > show single_field_name as required empty field (must be explicitly set)
   > block config submission until single_field_name is provided
   > In this case, we need set key_field_name and single_field_name are 
required when read_key_enabled=true
   >
   > Given the second scenario, it's advisable to explicitly set both 
parameters.
   https://github.com/apache/seatunnel/pull/9574#discussion_r2222810568
   Sure — but I’m a bit confused now, because previously another reviewer 
suggested adding
   ```java
   .conditional(READ_KEY_ENABLED, true, SINGLE_FIELD_NAME, KEY_FIELD_NAME)
   ```
   in order to make both `single_field_name` and `key_field_name` required (for 
stricter validation in the Web UI when `read_key_enabled = true`).
   
   Now it sounds like `key_field_name` should not be required because there is 
a default value.
   
   These two suggestions seem to conflict with each other — could you please 
advise which behavior we should follow?
   



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