Rushabh Shah created PHOENIX-7272:
-------------------------------------
Summary: Increment Sequence Number should be a separate RPC method
in MetaDataEndpointImpl.
Key: PHOENIX-7272
URL: https://issues.apache.org/jira/browse/PHOENIX-7272
Project: Phoenix
Issue Type: Bug
Affects Versions: 5.1.3
Reporter: Rushabh Shah
Currently we increment the sequence of the base table whenever we create a view
or alter the view (when we add new columns to the view) like this. Refer code
[here|https://github.com/apache/phoenix/blob/master/phoenix-core-client/src/main/java/org/apache/phoenix/schema/MetaDataClient.java#L413-L419].
{noformat}
private static final String INCREMENT_SEQ_NUM =
"UPSERT INTO " + SYSTEM_CATALOG_SCHEMA + ".\"" +
SYSTEM_CATALOG_TABLE + "\"( " +
TENANT_ID + "," +
TABLE_SCHEM + "," +
TABLE_NAME + "," +
TABLE_SEQ_NUM +
") VALUES (?, ?, ?, ?)";
if (tableType == VIEW && !changedCqCounters.isEmpty()) {
PreparedStatement incrementStatement =
connection.prepareStatement(INCREMENT_SEQ_NUM);
incrementStatement.setString(1, null);
incrementStatement.setString(2,
viewPhysicalTable.getSchemaName().getString());
incrementStatement.setString(3,
viewPhysicalTable.getTableName().getString());
incrementStatement.setLong(4,
viewPhysicalTable.getSequenceNumber() + 1);
incrementStatement.execute();
}
{noformat}
We are generating the new sequence number on the client side. It is possible
that the cached PTable (viewPhysicalTable in above example) could be stale (if
UCF is set to some value or NEVER).
Instead of creating an UPSERT command on the client side, we should create a
new co proc method on MetadataEndpointImpl co proc something like:
bq. public void incrementSeqNumber(tenantID, schemaName, tableName, int
originalSeqNum)
This RPC should fail if the current sequence number (stored in SYSCAT table)
doesn't match with the originalSeqNum. Similar to checkAndPut behavior in hbase.
This has the following benefits:
1. We will lock the table while running the RPC
2. Once PHOENIX-6883 is committed, we will be able to invalidate the cache for
the table on all regionservers.
3. If needed, we can increase the last ddl timestamp for the table.
4. If the sequence number doesn't match, the client will refresh its cache and
will resolve the table again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
