This sounds like a good plan overall, but I have a couple of notes:
1. We need to keep in mind that users plug in their own catalogs, so
iceberg.catalog could be a Glue or Nessie catalog, not just Hive or
Hadoop. I don’t think it makes much sense to use separate hadoop.catalog
and hive
Thanks, Peter. I answered inline.
On Mon, Nov 30, 2020 at 3:13 PM Peter Vary
wrote:
> Hi Zoltan,
>
> Answers below:
>
> On Nov 30, 2020, at 14:19, Zoltán Borók-Nagy <
> borokna...@cloudera.com.INVALID> wrote:
>
> Hi,
>
> Thanks for the replies. My take for the above questions are as follows
>
>
Hi Zoltan,
Answers below:
> On Nov 30, 2020, at 14:19, Zoltán Borók-Nagy
> wrote:
>
> Hi,
>
> Thanks for the replies. My take for the above questions are as follows
> Should 'iceberg.catalog' be a required property?
> Yeah, I think it would be nice if this would be required to avoid any
> im
Hi,
Thanks for the replies. My take for the above questions are as follows
- Should 'iceberg.catalog' be a required property?
- Yeah, I think it would be nice if this would be required to avoid any
implicit behavior
- 'hadoop.catalog' LOCATION and catalog_location
- In Impala
Hi,
Based on the discussion below I understand we have the following kinds of
properties:
Iceberg table properties - Engine independent, storage related parameters
"how to get to" - I think these are mostly Hive table specific properties,
since for Spark, the Spark catalog configuration serves f
