voonhous opened a new pull request, #20007: URL: https://github.com/apache/hudi/pull/20007
### Describe the issue this Pull Request addresses Closes #20002 Trino's lakehouse connector reuses the Hudi connector classes but cannot install `HudiModule`, so it provides the bindings `HudiSplitManager` needs itself (trinodb/trino#30682). The metastore getter calls the package-private `HudiMetadata.getMetastore()`, so lakehouse falls back to `HiveMetastoreFactory.createMetastore(...)` on every `getSplits` call. That bypasses the transaction-scoped metastore, so `hudi.per-transaction-metastore-cache-maximum-size` does nothing in lakehouse catalogs. ### Summary and Changelog Lakehouse catalogs can use the same transaction-scoped metastore and executors as the Hudi connector by installing one module. - New public `HudiExecutorModule`: the table-statistics, split-manager and split-loader executors (with their closing-binder registrations) plus the transaction-scoped metastore getter, moved unchanged from `HudiModule`. - `HudiModule` installs `HudiExecutorModule`. Trino's own module had this name before RFC-105, so `LakehouseHudiModule` can go back to `binder.install(new HudiExecutorModule())` and drop its copies. ### Impact New public Guice module in `hudi-trino`; no behavior change for the Hudi connector. ### Risk Level low - bindings moved verbatim; `TestHudiPlugin` and `TestHudiConnectorFactory` boot the connector through them. ### Documentation Update none ### Contributor's checklist - [x] Read through [contributor's guide](https://hudi.apache.org/contribute/how-to-contribute) - [x] Enough context is provided in the sections above - [x] Adequate tests were added if applicable -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
