You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "James Taylor (JIRA)" <ji...@apache.org> on 2014/08/20 09:12:27 UTC
[jira] [Updated] (PHOENIX-1189) Tighten up check for metadata being
out-of-date at commit time
[ https://issues.apache.org/jira/browse/PHOENIX-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Taylor updated PHOENIX-1189:
----------------------------------
Description:
We check that the results of our previously run, but not yet committed statements are valid in MutationState. There are corner cases we're not checking, though:
- If a table was dropped and a new one recreated with the same name
- If a column was removed and then re-added with the same name but a different type.
- If a column was removed and then a different one was added when no columns are explicitly named in an UPSERT statement.
If these changes occur in a different client, then we'll run into potential issues. As long as different column names are used (except for the last case), we're ok.
If possible, we should catch these situations (in the last case), and retry them again.
An alternative to this is to always check if the metadata is up-to-date when we compile the statement. When transactions are implemented, we should re-visit this flow.
was:
We check that the results of our previously run, but not yet committed statements are valid in MutationState. There are corner cases we're not checking, though:
- If a table was dropped and a new one recreated with the same name
- If a column was removed and then re-added with the same name but a different type.
- If a column was removed and then a different one was added when no columns are explicitly named in an UPSERT statement.
If these changes occur in a different client, then we'll run into potential issues. As long as different column names are used (except for the last case), we're ok.
If possible, we should catch these situations (in the last case), and retry them again.
> Tighten up check for metadata being out-of-date at commit time
> --------------------------------------------------------------
>
> Key: PHOENIX-1189
> URL: https://issues.apache.org/jira/browse/PHOENIX-1189
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
>
> We check that the results of our previously run, but not yet committed statements are valid in MutationState. There are corner cases we're not checking, though:
> - If a table was dropped and a new one recreated with the same name
> - If a column was removed and then re-added with the same name but a different type.
> - If a column was removed and then a different one was added when no columns are explicitly named in an UPSERT statement.
> If these changes occur in a different client, then we'll run into potential issues. As long as different column names are used (except for the last case), we're ok.
> If possible, we should catch these situations (in the last case), and retry them again.
> An alternative to this is to always check if the metadata is up-to-date when we compile the statement. When transactions are implemented, we should re-visit this flow.
--
This message was sent by Atlassian JIRA
(v6.2#6252)