[
https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16495792#comment-16495792
]
ASF GitHub Bot commented on PHOENIX-3534:
-----------------------------------------
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/303#discussion_r191940463
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java
---
@@ -1995,36 +2287,46 @@ public void dropTable(RpcController controller,
DropTableRequest request,
try {
List<Mutation> tableMetadata =
ProtobufUtil.getMutations(request);
+ List<Mutation> childLinkMutations = Lists.newArrayList();
MetaDataUtil.getTenantIdAndSchemaAndTableName(tableMetadata,
rowKeyMetaData);
byte[] tenantIdBytes =
rowKeyMetaData[PhoenixDatabaseMetaData.TENANT_ID_INDEX];
schemaName =
rowKeyMetaData[PhoenixDatabaseMetaData.SCHEMA_NAME_INDEX];
tableName =
rowKeyMetaData[PhoenixDatabaseMetaData.TABLE_NAME_INDEX];
+ PTableType
pTableType=PTableType.fromSerializedValue(tableType);
// Disallow deletion of a system table
- if (tableType.equals(PTableType.SYSTEM.getSerializedValue())) {
+ if (pTableType == PTableType.SYSTEM) {
builder.setReturnCode(MetaDataProtos.MutationCode.UNALLOWED_TABLE_MUTATION);
builder.setMutationTime(EnvironmentEdgeManager.currentTimeMillis());
done.run(builder.build());
return;
}
+
List<byte[]> tableNamesToDelete = Lists.newArrayList();
List<SharedTableState> sharedTablesToDelete =
Lists.newArrayList();
- // No need to lock parent table for views
- byte[] parentTableName =
MetaDataUtil.getParentTableName(tableMetadata);
- byte[] lockTableName = parentTableName == null ||
tableType.equals(PTableType.VIEW.getSerializedValue()) ? tableName :
parentTableName;
- byte[] lockKey = SchemaUtil.getTableKey(tenantIdBytes,
schemaName, lockTableName);
- byte[] key =
- parentTableName == null ? lockKey :
SchemaUtil.getTableKey(tenantIdBytes,
- schemaName, tableName);
+
+ byte[] lockKey = SchemaUtil.getTableKey(tenantIdBytes,
schemaName, tableName);
Region region = env.getRegion();
- MetaDataMutationResult result = checkTableKeyInRegion(key,
region);
+ MetaDataMutationResult result = checkTableKeyInRegion(lockKey,
region);
if (result != null) {
done.run(MetaDataMutationResult.toProto(result));
return;
}
- PTableType
ptableType=PTableType.fromSerializedValue(tableType);
+
+ byte[] parentTableName =
MetaDataUtil.getParentTableName(tableMetadata);
+ byte[] parentLockKey = null;
+ // No need to lock parent table for views
+ if (parentTableName != null && pTableType != PTableType.VIEW) {
+ parentLockKey = SchemaUtil.getTableKey(tenantIdBytes,
schemaName, parentTableName);
--- End diff --
Shouldn't need this parentLockKey any longer, yes? Or is this only for
indexes?
> Support multi region SYSTEM.CATALOG table
> -----------------------------------------
>
> Key: PHOENIX-3534
> URL: https://issues.apache.org/jira/browse/PHOENIX-3534
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: Thomas D'Silva
> Priority: Major
> Attachments: PHOENIX-3534-wip.patch
>
>
> Currently Phoenix requires that the SYSTEM.CATALOG table is single region
> based on the server-side row locks being held for operations that impact a
> table and all of it's views. For example, adding/removing a column from a
> base table pushes this change to all views.
> As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431),
> when a new table is created we can do a lazy cleanup of any rows that may be
> left over from a failed DDL call (kudos to [~lhofhansl] for coming up with
> this idea). To implement this efficiently, we'd need to also do PHOENIX-2051
> so that we can efficiently find derived views.
> The implementation would rely on an optimistic concurrency model based on
> checking our sequence numbers for each table/view before/after updating. Each
> table/view row would be individually locked for their change (metadata for a
> view or table cannot span regions due to our split policy), with the sequence
> number being incremented under lock and then returned to the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
