The IMetaStoreClient API already has 12 dropPartition variants and it seems a bit surprising that we don't have a method to satisfy use-case no. 2 efficiently. Have we examined all existing methods?
If we plan to add a new method in this interface then we should do it carefully in a way that we won't be forced to modify again in the near future. It is good to have shortcuts for common use-cases but an interface with 12+ overloaded methods and more than 4+ parameters each is far from user-friendly. In that sense providing a method with a DropPartitionsRequest object makes more sense but still we have to double-check that there is no other alternative. Best, Stamatis On Wed, Jul 16, 2025 at 7:08 PM Wechar Yu <yuwq1...@gmail.com> wrote: > > > however, can we wrap everything into the `DropPartitionsRequest` instead of > > introducing 2 API methods > > Hi Denys, do you mean add an API that accept the `DropPartitionsRequest` as a > parameter like: > > List<Partition> dropPartitions(DropPartitionsRequest req) > > It would be the same as rest api `drop_partitions_req(DropPartitionsRequest > req)`, I believe the hive client could offer a more user-friendly interface > by abstracting away the need for users to manually construct the entire > DropPartitionsRequest object. > Additionally, using `TableName` is a clean and intuitive approach. > > On Wed, Jul 16, 2025 at 12:47 AM Denys Kuzmenko <dkuzme...@apache.org> wrote: >> >> or at least replace with TableName: >> >> List<Partition> dropPartitions(TableName table, >> RequestPartsSpec partsSpec, PartitionDropOptions options)
