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/03/17 21:06:24 UTC

[GitHub] [hudi] alexeykudinkin commented on pull request #4957: [HUDI-3406] Rollback incorrectly relying on FS listing instead of Com…

alexeykudinkin commented on pull request #4957:
URL: https://github.com/apache/hudi/pull/4957#issuecomment-1071493358


   Taking a step back here and looking at things more holistically I think we should actually approach it differently: we should actually change revisit this flow from how ListingBasedRollbackRequests are generated all the way to HoodieRollbackRequest generation.
   
   See, the flow right now does look like following for listing-based rollback:
   1. We first create `ListingBasedRollbackRequest` (there's not a lot of value in this abstraction since it is very shallow in itself, only contains `type` of the rollback and `partitionPath` which is obviously not enough to do the rollback)
   2. Then we actually create `HoodieRollbackRequest` based on the former ones
   
   Instead, we should combine these 2 steps into 1 very we directly generate `HoodieRollbackRequest` (similar to what MarkerBasedRollbackStrategy is doing). Flow would look like following in that case:
   1. If instant is completed — we rely on `CommitMetadata` to produce HoodieRollbackInstant
   2. If instant is incomplete — we actually list the files and do the instant based filtering
   
   cc @nsivabalan @xushiyan 


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