[
https://issues.apache.org/jira/browse/HIVE-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16300971#comment-16300971
]
Eugene Koifman commented on HIVE-18285:
---------------------------------------
this patch should not add any time to compilation since it only changes where
StatsTask gets the Table object when it runs. I believe this happens on the
client side and long after compilation is done.
bq. Secondly, logic to convert table type based on config to me seems to belong
to compiler. Metastore shall not govern that.
Table is a metadata object and whether a table supports Acid ops is a property
of this metadata object. Seems like Metastore is exactly the place to govern
metadata objects. Normally compiler just reads metadata objects.
Finally, perhaps most importantly: A large part of acid is in the metastore.
The entire state of compactor, lock manger, transaction manager is currently
managed by the metastore. This is very specific to Hive. If you don't think
Hive specific logic belongs in the metastore, where do you see all this logic
going once metastore becomes standalone?
> StatsTask uses a cached ql.metadata.Table object
> ------------------------------------------------
>
> Key: HIVE-18285
> URL: https://issues.apache.org/jira/browse/HIVE-18285
> Project: Hive
> Issue Type: Bug
> Components: Metastore, Statistics
> Reporter: Eugene Koifman
> Assignee: Eugene Koifman
> Attachments: HIVE-18285.01.patch
>
>
> this then causes BasicStatsTask.aggregateStats(Hive) to call
> Hive.alterTable() with a stale Table object. (It misses any changes made by
> any MetaStorePreEventListener)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
