-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Support drop partitions with common expressions #53118
base: main
Are you sure you want to change the base?
[Feature] Support drop partitions with common expressions #53118
Conversation
Signed-off-by: shuming.li <[email protected]>
} catch (Exception e) { | ||
throw new SemanticException("Failed to prune partitions with where expression: " + e.getMessage()); | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The most risky bug in this code is:
In the putValueMapItem
method, there is a risk of a concurrent modification exception because the partitionIdSet, once retrieved from the map, can be modified outside of the synchronization context before it is put back.
You can modify the code like this:
private static void putValueMapItem(ConcurrentNavigableMap<LiteralExpr, Set<Long>> partitionValueToIds,
Long partitionId,
LiteralExpr value) {
partitionValueToIds.compute(value, (k, partitionIdSet) -> {
if (partitionIdSet == null) {
partitionIdSet = new HashSet<>();
}
partitionIdSet.add(partitionId);
return partitionIdSet;
});
}
This change uses compute
which safely adds partitionId
to the set associated with value
without risking concurrent modification issues.
} | ||
|
||
public Expr getDropWhereExpr() { | ||
return dropWhereExpr; | ||
} | ||
|
||
public List<String> getResolvedPartitionNames() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The most risky bug in this code is:
Potential null pointer dereference due to assumptions about partition lists.
You can modify the code like this:
// Before accessing any fields that may be null, check for null references.
public DropPartitionClause(boolean ifExists, Expr whereExpr, boolean isTempPartition,
boolean forceDrop, NodePosition pos) {
super(AlterOpType.DROP_PARTITION, pos);
this.ifExists = ifExists;
this.partitionName = null;
this.isTempPartition = isTempPartition;
this.forceDrop = forceDrop;
this.multiRangePartitionDesc = null;
this.partitionNames = new ArrayList<>(); // Ensure partitionNames is initialized to prevent null access.
this.dropWhereExpr = whereExpr;
}
Make sure the partitionNames
or any potentially nullable field is either checked before use or given a safe default (like an empty list). This helps avoid null pointer exceptions when the object is used elsewhere in the system.
.getDb(context.getCurrentCatalog(), context.getDatabase()); | ||
TableName tableName = new TableName(db.getFullName(), table.getName()); | ||
List<String> dropPartitionNames = ListPartitionPruner.getPartitionNamesByExpr(olapTable, tableName, expr, context); | ||
clause.setResolvedPartitionNames(dropPartitionNames); | ||
} | ||
|
||
if (table instanceof OlapTable) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The most risky bug in this code is:
Incorrect conditions in if-else statements that can lead to semantic exceptions for unsupported table types.
You can modify the code like this:
@Override
public Void visitDropPartitionClause(DropPartitionClause clause, ConnectContext context) {
if (clause.getMultiRangePartitionDesc() != null) {
if (!(table instanceof OlapTable)) {
throw new SemanticException("Can't drop partitions with multi-range since its table type is not olap");
}
MultiRangePartitionDesc multiRangePartitionDesc = clause.getMultiRangePartitionDesc();
PartitionDescAnalyzer.analyze(multiRangePartitionDesc);
OlapTable olapTable = (OlapTable) table;
PartitionDescAnalyzer.analyzePartitionDescWithExistsTable(multiRangePartitionDesc, olapTable);
PartitionInfo partitionInfo = olapTable.getPartitionInfo();
List<String> dropPartitionNames = multiRangePartitionDesc.convertToSingleRangePartitions(partitionInfo);
clause.setResolvedPartitionNames(dropPartitionNames);
} else if (clause.getPartitionNames() != null) {
clause.setResolvedPartitionNames(clause.getPartitionNames());
} else if (clause.getDropWhereExpr() != null) {
if (!(table instanceof OlapTable)) {
throw new SemanticException("Can't drop partitions with where expression since its table type is not olap");
}
OlapTable olapTable = (OlapTable) table;
Expr expr = clause.getDropWhereExpr();
Database db = context.getGlobalStateMgr().getMetadataMgr()
.getDb(context.getCurrentCatalog(), context.getDatabase());
TableName tableName = new TableName(db.getFullName(), table.getName());
List<String> dropPartitionNames = ListPartitionPruner.getPartitionNamesByExpr(olapTable, tableName, expr, context);
clause.setResolvedPartitionNames(dropPartitionNames);
}
if (table instanceof OlapTable) {
// any additional logic for OlapTable
}
}
Explanation:
- Placement and order of
MultiRangePartitionDesc multiRangePartitionDesc
initialization: In the original code, there's a risk because initialization should happen only after confirming the table type asOlapTable
. - Ensuring the
if
conditions align logically with their use case to prevent invalid operations on non-Olap tables. - It ensures that both types of partition dropping verifications are correctly placed and don't leak erroneous behaviors on different table types.
Signed-off-by: shuming.li <[email protected]>
a0e136e
to
3ade038
Compare
Quality Gate passedIssues Measures |
[Java-Extensions Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
[FE Incremental Coverage Report]✅ pass : 141 / 148 (95.27%) file detail
|
[BE Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
Why I'm doing:
What I'm doing:
Fixes #53117
What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist:
Bugfix cherry-pick branch check: