You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hudi.apache.org by GitBox <gi...@apache.org> on 2022/09/01 18:38:43 UTC

[GitHub] [hudi] nsivabalan commented on a diff in pull request #6548: [HUDI-4749] Fixing full cleaning to leverage metadata table

nsivabalan commented on code in PR #6548:
URL: https://github.com/apache/hudi/pull/6548#discussion_r960987424


##########
hudi-client/hudi-client-common/src/main/java/org/apache/hudi/table/action/clean/CleanPlanner.java:
##########
@@ -206,15 +206,7 @@ private List<String> getPartitionPathsForIncrementalCleaning(HoodieCleanMetadata
    */
   private List<String> getPartitionPathsForFullCleaning() {
     // Go to brute force mode of scanning all partitions
-    try {
-      // Because the partition of BaseTableMetadata has been deleted,
-      // all partition information can only be obtained from FileSystemBackedTableMetadata.

Review Comment:
   yeah. when Sagar wrote that code, here is how DELETE_PARTITION was implemented. 
   it wasn't well thought out design/impl. The way it was designed was, partition was synchronously deleted in data table and replace commit was relayed to MDT where in all file groups will be marked as invalid. but the partition in MDT remained. 
   
   if you remember, I chimed in and rewrote the entire impl, where in we made DELETE_PARTITION lazy. 
   



-- 
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: commits-unsubscribe@hudi.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org