Hi, We have successfully merged HIVE-27473! We no longer need to worry about a massive conflict on this area. Thank you all for your patience. Thank you, Seonggon, for your fantastic contribution!
Best, Okumin On Sat, Jul 5, 2025 at 6:29 PM Shohei Okumiya <oku...@apache.org> wrote: > > Hi all, > > I'm reporting the progress of HIVE-27473, and I have one request. > > Thanks to Seonggon's enormous effort, we're about to take a giant step > in solving the 10-year problem[1]. This will explore the new > possibility for Hive to integrate with more systems, thereby improving > the maintainability of the IMetaStoreClient. It's an excellent work! > https://github.com/apache/hive/pull/5771 > > As you can see, the pull request updates numerous large files because > we're restructuring the IMetaStoreClient family, which has > approximately 400 methods. We have probably spent more than 100 hours > on the problem, and we're currently loading the huge change into our > human memory. When a massive conflict happens, we need to reallocate > our time and space again. I'd be delighted if you could respectfully > avoid applying significant changes to related files until we merge > #5771. > > We will update the status when we complete it or it turns out not to > be smoothly merged. > > - [1] HIVE-12679 > > Best regards, > Okumin > > On Thu, May 8, 2025 at 6:30 AM Chris Nauroth <cnaur...@apache.org> wrote: > > > > Thank you for starting this discussion, Seonggon. > > > > I am also +1 (non-binding) for option 1: pluggable IMetaStoreClient. This > > is the most realistic path for actual adoption, considering multiple > > existing integrations. (Disclaimer: I work for a company that has > > implemented a variant of HIVE-12679 in a private fork.) > > > > Chris Nauroth > > > > > > On Sun, May 4, 2025 at 12:19 AM Shohei Okumiya <oku...@apache.org> wrote: > >> > >> Hi Seonggon, > >> > >> Thanks for being involved with the ticket, trying a PoC, and > >> initiating the discussion on ML. > >> > >> I am currently biased toward Option 1 for some reasons. > >> - Option 1 likely has some existing users > >> - Option 1 can improve the maintainability of > >> SessionHiveMetaStoreClient and its family. It's nice, even if we find > >> Option 2 is more convenient later > >> - The primary disadvantage of Option 1, i.e., many overridden methods > >> in IMetaStoreClient, can be mitigated if we gradually deprecate and > >> clean up these methods > >> - In the worst case, we can additionally implement Option 2. We can do > >> what we want to do, and some tech debts will be gone > >> > >> Best, > >> Okumin > >> > >> On Wed, Apr 30, 2025 at 8:39 PM Denys Kuzmenko <dkuzme...@apache.org> > >> wrote: > >> > > >> > +1 for Option 1: Make IMetaStoreClient pluggable