[
https://issues.apache.org/jira/browse/HIVE-18444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eugene Koifman updated HIVE-18444:
----------------------------------
Description:
if a user creates a new transactional table but sets a location to some place
that already has data any number of things can break.
Data may not be in Acid format, it may have been written by another cluster and
txnids won't make sense in current cluster. Once per table writeIDs
(HIVE-18192) are there, if the data was written by another table, writeIDs
won't match.
This could actually work if the data at the existing location was not written
by an acid write but it would be safer/cleaner to just prevent this (at least
at first).
was:
if a user creates a new transactional table but sets a location to some place
that already has data any number of things can break.
Data may not be in Acid format, it may have been written by another cluster and
txnids won't make sense in current cluster. Once per table writeIDs are there,
if the data was written by another table, writeIDs won't match.
This could actually work if the data at the existing location was not written
by an acid write but it would be safer/cleaner to just prevent this (at least
at first).
> when creating transactional table make sure location has no data
> ----------------------------------------------------------------
>
> Key: HIVE-18444
> URL: https://issues.apache.org/jira/browse/HIVE-18444
> Project: Hive
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 1.0.0
> Reporter: Eugene Koifman
>
> if a user creates a new transactional table but sets a location to some place
> that already has data any number of things can break.
> Data may not be in Acid format, it may have been written by another cluster
> and txnids won't make sense in current cluster. Once per table writeIDs
> (HIVE-18192) are there, if the data was written by another table, writeIDs
> won't match.
> This could actually work if the data at the existing location was not written
> by an acid write but it would be safer/cleaner to just prevent this (at least
> at first).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
