You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Bowen Li (JIRA)" <ji...@apache.org> on 2019/06/18 22:18:00 UTC

[jira] [Commented] (FLINK-12841) Unify catalog meta-objects implementations

    [ https://issues.apache.org/jira/browse/FLINK-12841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867088#comment-16867088 ] 

Bowen Li commented on FLINK-12841:
----------------------------------

[~dawidwys] Make sense to me, I was also rethinking that part. I will unify implementations and keep interfaces, also rephrased the title.

> Unify catalog meta-objects implementations
> ------------------------------------------
>
>                 Key: FLINK-12841
>                 URL: https://issues.apache.org/jira/browse/FLINK-12841
>             Project: Flink
>          Issue Type: Sub-task
>          Components: Connectors / Hive, Table SQL / API
>    Affects Versions: 1.9.0
>            Reporter: Bowen Li
>            Assignee: Bowen Li
>            Priority: Major
>             Fix For: 1.9.0
>
>
> We've been evaluating the original design in FLIP-30 that proposed creating catalog meta object interfaces and individual impl of those interfaces in each catalog. Interfaces we have so far are: {{CatalogDatabase}}, {{CatalogTable}}, {{CatalogView}}, {{CatalogPartition}}, {{CatalogFunction}}, and e.g. for {{CatalogTable}} interface, we have impls of {{GenericCatalogTable}} and {{HiveCatalogTable}}, etc.
> Well, we have gone pretty far on FLIP-30 now. When we look back and re-evaluate this design, we actually found there are not many differences between, e.g. {{GenericCatalogTable}} and {{HiveCatalogTable}}. And having this class hierarchy complicates situations and development. E.g. this requires sql client to have a hard dependency on flink-connector-hive in order to create {{HiveCatalogTable}} from DDL, which I don't think is necessary.
> On the other side in Blink, we don't have this hierarchy and have been just using a single meta-object class (e.g. just {{CatalogTable}}) to represent data in different catalogs, it has been fine without any problem and all the difference among catalogs can be stored as properties.
> Thus we propose removing the inheritance hierarchy and impl of the meta-object interfaces for each individual catalog. To be more specific, take table classes for example, we will replace {{CatalogTable}} with existing {{AbstractCatalogTable}}, and remove {{GenericCatalogTable}} and {{HiveCatalogTable}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)