[
https://issues.apache.org/jira/browse/PHOENIX-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14586252#comment-14586252
]
Maryann Xue commented on PHOENIX-1812:
--------------------------------------
The failed case after the above change is
"AlterTableIT.testDropColumnsWithImutability()", which expects a
TableNotFoundException for the index table after dropping index columns.
I think there might be a bug in the MetadataClient, which got a
MutationCode.TABLE_NOT_FOUND and decided to remove the table from the cache.
But it would still return the PTable and the caller would think the table still
exists. The below change fixes the problem.
{code}
@@ -450,6 +450,7 @@ public class MetaDataClient {
// If table was not found at the current time stamp and we
have one cached, remove it.
// Otherwise, we're up to date, so there's nothing to do.
if (code == MutationCode.TABLE_NOT_FOUND && tryCount + 1
== maxTryCount) {
+ result.setTable(null);
connection.removeTable(tenantId, fullTableName,
table.getParentName() == null ? null : table.getParentName().getString(),
table.getTimeStamp());
}
}
{code}
BTW, the resolve-twice problem has long been there since the very initial
check-in for join query support. PHOENIX-1489 was trying to avoid double
resolving by add an additional TableRef equality check, which eventually only
works for those cases that do not use "positional access" logic introduced by
PHOENIX-1489 (like aggregate query). Otherwise, this check SHOULD return false
and the resolver should be set again for where clause compilation, and it's
only that we should the right "getResolver" method to avoid resolving the table
twice, which is why I suggested that change.
> Only sync table metadata when necessary
> ---------------------------------------
>
> Key: PHOENIX-1812
> URL: https://issues.apache.org/jira/browse/PHOENIX-1812
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: James Taylor
> Assignee: Thomas D'Silva
> Attachments: PHOENIX-1812.patch, PHOENIX-1812.patch
>
>
> With transactions, we hold the timestamp at the point when the transaction
> was opened. We can prevent the MetaDataEndpoint getTable RPC in
> MetaDataClient.updateCache() to check that the client has the latest table if
> we've already checked at the current transaction ID timestamp. We can keep
> track of which tables we've already updated in PhoenixConnection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
