rakeshadr commented on a change in pull request #1923:
URL: https://github.com/apache/ozone/pull/1923#discussion_r577576297
##########
File path:
hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/request/s3/multipart/S3MultipartUploadCommitPartRequestV1.java
##########
@@ -147,8 +148,18 @@ public OMClientResponse
validateAndUpdateCache(OzoneManager ozoneManager,
// Set the UpdateID to current transactionLogIndex
omKeyInfo.setUpdateID(trxnLogIndex, ozoneManager.isRatisEnabled());
- String ozoneKey = omMetadataManager.getOzonePathKey(parentID, fileName);
- partName = ozoneKey + clientID;
+ /**
+ * Format of PartName stored into MultipartInfoTable is,
+ * "fileName + ClientID".
+ *
+ * Contract is that all part names present in a multipart info will
+ * have same key prefix path.
+ *
+ * For example:
+ * /vol1/buck1/a/b/c/part-1, /vol1/buck1/a/b/c/part-2,
+ * /vol1/buck1/a/b/c/part-n
+ */
+ dbPartName = fileName + clientID;
Review comment:
In the V0 (existing code), `PartName` is constructed using the `partName
= ozoneKey + clientID;`.
Now, in FSOBucket feature code, we store only the `fileName` in the
`fileTable` and reconstructed `fullKeyName` while reading back from it. I
thought of following the same format pattern the `multipartFileInfoTable` as
well. Yes, like you said, we need to reconstruct it during #complete or #abort
or #listParts etc.
Following is the PartKeyInfo proto object. There we can see KeyInfo, which
inturn has `parentID` and is having similar structure with other V1(FSOBucket
feature) tables. I think, it would be helpful if we could follow same pattern
everywhere in the new tables for better debugging unless if there is any
functional challenges. Does that make sense to you?
```
message PartKeyInfo {
required string partName = 1;
required uint32 partNumber = 2;
required KeyInfo partKeyInfo = 3;
}
```
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
