[I] Fix upgrade/downgrade to also upgrade MT in the same way [hudi]

["hudi-bot (via GitHub)" <gi...@apache.org>]

hudi-bot opened a new issue, #17272:
URL: https://github.com/apache/hudi/issues/17272

   # Do we need a forceDowngrade write config?
    # Break apart upgrade and downgrade methods inside UpgradeDowngrade class path.. 
    # change package to "versioning.migration"
   
    
   
    
   
   Testing: 
   
   1. TestMultipleTableVersionWriting needs to check for a specific exception like upgrade/downgrade>=?
   
    
   
   ## JIRA info
   
   - Link: https://issues.apache.org/jira/browse/HUDI-8237
   - Type: Sub-task
   - Parent: https://issues.apache.org/jira/browse/HUDI-8229
   - Fix version(s):
     - 1.1.0


-- 
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.apache.org

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

Re: [I] Fix upgrade/downgrade to also upgrade MT in the same way [hudi]

["rangareddy (via GitHub)" <gi...@apache.org>]

rangareddy commented on issue #17272:
URL: https://github.com/apache/hudi/issues/17272#issuecomment-5365810148

   This issue was reviewed as part of the JIRA-migrated backlog triage (HUDI-8237).
   
   **Findings: not resolvable by code inspection alone.**
   
   The description is a four-part checklist. One item is directly verifiable and has not happened: the package move. The upgrade/downgrade handlers still live in `org.apache.hudi.table.upgrade` (`hudi-client/hudi-client-common/src/main/java/org/apache/hudi/table/upgrade/` - `SevenToEightUpgradeHandler`, `EightToSevenDowngradeHandler`, `SevenToSixDowngradeHandler`, etc.), not in a `versioning.migration` package.
   
   The other three items - a `forceDowngrade` write config, splitting the upgrade and downgrade methods, and having `TestMultipleTableVersionWriting` assert a specific exception - are best confirmed by whoever owns the parent effort, since the first of them is a design decision rather than a refactor.
   
   Worth splitting this ticket: the package move and method split are mechanical and could land now; the `forceDowngrade` config needs a decision about what it is allowed to skip.
   
   Keeping this open.
   


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