[
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)
