[
https://issues.apache.org/jira/browse/IMPALA-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16766269#comment-16766269
]
ASF subversion and git services commented on IMPALA-7128:
---------------------------------------------------------
Commit 55da35e9fe4d6ccc08662c0cf17961a987183646 in impala's branch
refs/heads/2.x from Todd Lipcon
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=55da35e ]
IMPALA-7128 (part 1) Refactor interfaces for Db, View, Table, Partition
This refactors out interfaces in the frontend for the interaction
between the analysis/planning code and the classes that implement
these catalog objects.
This takes care of the most commonly used objects but defers some others
(e.g. functions, cache pools, data sources, etc) to follow-on patches.
There are a few spots remaining in the frontend that still downcast to
implementation classes, particularly where the frontend actually makes
modifications to catalog objects in-place. I left TODOs in those spots
and will come back later as necessary.
Change-Id: Id55f7d2e94d81e66ce720acb6315f15a89621b31
Reviewed-on: http://gerrit.cloudera.org:8080/10611
Reviewed-by: Impala Public Jenkins <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>
Reviewed-on: http://gerrit.cloudera.org:8080/12345
Reviewed-by: Fredy Wijaya <[email protected]>
> Extract interfaces for frontend interaction with catalog objects
> ----------------------------------------------------------------
>
> Key: IMPALA-7128
> URL: https://issues.apache.org/jira/browse/IMPALA-7128
> Project: IMPALA
> Issue Type: Sub-task
> Components: Catalog, Frontend
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Major
> Fix For: Impala 3.1.0
>
>
> Currently both the catalogd and the impalad use the same implementation
> classes for catalog objects such as Table, Function, HdfsPartition, etc.
> Those implementations are fairly tightly coupled to the current design of the
> catalog.
> For the new catalog design, it will be easier to have a new set of classes
> rather than attempting to reuse or modify the existing ones for a few reasons:
> - the existing ones are mutable in the catalogd and thus have to worry quite
> a bit about synchronization, whereas the new design uses immutable catalog
> objects
> - the existing ones assume "all or nothing" loading whereas the new design
> involves lazy-loading relevant bits of info
> - we don't want to destabilize the existing implementation, so we want to
> avoid any nontrivial modifications of the existing code.
> Extracting a set of interfaces such as 'FeTable', 'FeDb', etc, will help
> decouple the frontend from the particular catalog implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
