Hi Anurag, The _req methods request a structural argument, make it easier to manage the version compatibility of Metastore during API evolving, such as adding, renaming or removing fields within a struct wouldn't cause the breaking change, the HMS doesn't need to introduce new variant methods in such cases, and older versions of the client still use the same contract and assumptions to communicate with the new Metastore. As of now, we have covered the methods which are prone to evolve, mostly operate on the table/partition, the catalog name is defined as optional in the struct, so you need to specify it unless you really need to. The IMetaStoreClient is the interface exposing to the caller, you don't need to care about the _req method when you upgrade the Hive version. If you use the raw thrift to talk to HMS, I would recommend using the new _req methods, as we might remove the legacy deprecated methods in the future.
Regards, Zhihua On 2024/12/16 12:54:51 Anurag Kumar Dwivedi wrote: > Hi Hive Community, > > I hope everyone is doing well! I wanted to initiate a discussion regarding > the recently introduced _req methods in the Hive Metastore (HMS). There are a > few areas where your insights would be invaluable: > Adoption by Other Projects (Presto/Spark): > Should engines like Presto and Spark also consider adopting the _req methods? > Are there any ongoing or planned efforts to align these engines with the new > APIs? > I can see the catalog name can also be passed as part of the request body of > new methods, so is it expected that engines like (presto/Spark) should also > start passing to metastore layer. > Community Thinking Behind the New Methods: > What was the driving thought process or specific use cases that led to the > introduction of these methods? > How do these methods enhance functionality, performance, or usability > compared to existing ones? > Target Consumers of the New APIs: > Who are the intended consumers of these new APIs? Are they primarily aimed at > specific applications or frameworks? > Are there any expected challenges or benefits for early adopters? > Catalog name passed along with schema name : > HMS code does support passing the catalog name being passed along with schema > name sperated by “#”. So Is that being used by the java clients only or its a > work around till the engines switches to the new _req methods which already > have catalog name. > This information would not only help us understand the roadmap better but > also guide downstream engines like Presto and Spark in making informed > decisions. > Looking forward to your thoughts and feedback! > > Best regards, > Anurag Dwivedi
