I just filed https://github.com/apache/polaris/issues/540 to track this
feature request, and wrote up this document to try to better solidify our
terminology and concepts on related federation features, while also
sketching out a proposal for a basic MVP of catalog federation that could
be easily e
When I said "migrate", I specifically meant the feature to actually move
the tables to a new source catalog. Polaris as a _path_ to migration
definitely should be a core feature - it's the reason External catalogs are
supported at all. Adding full delegation, IMO, helps fulfill the purpose of
Exter
I think it's really important that we have the functionality to move folks
off of existing catalog solutions be they Hive, Hadoop or what not. I do
think, even with the dependency issues, this should be a core functionality
of Polaris. I think this would make it much easier for folks on non-REST
ca
IMO, anything that's not directly managed by Polaris source code is
external. If someone can create a table directly in the other catalog and
it shows up in Polaris, it's external.
As of now, all of the direct manipulation APIs are blocked for external
catalogs - createTable, updateTable, etc. I t
Haven't read the proposal yet (so bear with me ;) )
Integrating other Iceberg catalogs is a great idea! However, should we
maybe concentrate only on linking to external REST based catalogs and
let the remote ones deal with "specialties" like how often to list
namespaces/tables/views and whethe
Hi Y’all,
Some of us at Snowflake and Revolut have been talking a bit about how
Apache Polaris can be used in conjunction with older implementations of
Apache Iceberg Catalogs. At Revolut, they have already built a version of
this which allows them to use Polaris Capabilities on top of an old Cata
