Hi HadoopCatalog is not a "recommended" catalog for production (at least up to now). So, we should consider either to move it in a separate repo (if we have the guarantee that it's gonna be maintained, else it doesn't make sense) or remove it to avoid confusion. My take here is the same (for several months :)): we should privilege the REST Catalog API and users should use a REST Catalog server implementation.
Regards JB On Mon, Jul 15, 2024 at 8:13 AM lisoda <lis...@yeah.net> wrote: > > Sir. Even if the entire hadoopCatalog can be used without lockManager, should > we delete it? > > > > > > > 在 2024-07-15 14:08:40，"Jean-Baptiste Onofré" <j...@nanthrax.net> 写道： > >Hi > > > >My understanding is that lock manager is mostly used on the > >HadoopCatalog. The other catalogs relays on a third party lock > >mechanism: for instance, JDBC Catalog uses the RDBMS table/row > >locking, REST Catalog uses implementation lock. > >I would rather remove HadoopCatalog and the lock manager in favor of > >the REST catalog and implementation lock mechanism. > > > >Just my $0.01 :) > > > >Regards > >JB > > > >On Fri, Jul 12, 2024 at 7:41 AM lisoda <lis...@yeah.net> wrote: > >> > >> Currently, the only lockManager implementation in iceberg-core is > >> InMemoryLockManager. This PR extends two LockManager implementations, one > >> based on the Redis, and another based on the Rest-API. > >> In general, most users use redisLockManager is sufficient to cope with > >> most of the scenarios, for redis can not meet the user's requirements, we > >> can let the user to provide a RestApi service to achieve this function. I > >> believe that, for a long time, these two lock-manager's will satisfy most > >> of the customer's needs. > >> > >> If someone could review this PR, that would be great. > >> > >> PR: https://github.com/apache/iceberg/pull/10688 > >> SLACK: > >> https://apache-iceberg.slack.com/archives/C03LG1D563F/p1720761992982729
