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

Reply via email to