hudi-agent commented on code in PR #19591:
URL: https://github.com/apache/hudi/pull/19591#discussion_r3764298009


##########
website/docs/concurrency_control.md:
##########
@@ -188,6 +188,32 @@ com.amazonaws:aws-java-sdk-dynamodb
 com.amazonaws:aws-java-sdk-core
 ```
 
+### DynamoDB-Based Lock Provider with Implicit Partition Key
+
+```properties
+hoodie.write.lock.provider=org.apache.hudi.aws.transaction.lock.DynamoDBBasedImplicitPartitionKeyLockProvider
+```
+
+This variant behaves like the DynamoDB-based lock provider above, except in 
how it determines the DynamoDB partition
+key. Rather than reading `hoodie.write.lock.dynamodb.partition_key`, it 
derives the key from the table's base path: the
+64-bit xxHash of that path, with `s3a://` normalized to `s3://` so that 
writers reaching the same table through either
+scheme take the same lock.
+
+Prefer it when many tables share one lock table. The standard provider requires

Review Comment:
   🤖 This sentence reads as slightly self-contradictory: the standard provider 
"requires" the config but then "Hudi infers it from the table name" when unset. 
A reader may wonder whether it fails or silently falls back. It might help to 
phrase it as the requirement being satisfied by an infer function — e.g. "the 
standard provider needs `hoodie.write.lock.dynamodb.partition_key`; when it 
isn't set explicitly, Hudi infers it from the table name (rather than failing)" 
— to make clear no error is thrown and why the name-collision risk arises. Note 
this also sits slightly in tension with the existing DynamoDB section above 
(line 148), which describes the partition key as having a "default: table 
name"; aligning the two on "infers" vs "defaults" would avoid confusion.
   
   <sub><i>⚠️ AI-generated; verify before applying. React 👍/👎 to flag 
quality.</i></sub>



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