Closed mergify[bot] closed 3 months ago
Cherry-pick of 37d1b2966ecbe0ae9cf0920ee8d6715173d11a59 has failed:
On branch mergify/bp/branch-3.1/pr-47628
Your branch is up to date with 'origin/branch-3.1'.
You are currently cherry-picking commit 37d1b2966e.
(fix conflicts and run "git cherry-pick --continue")
(use "git cherry-pick --skip" to skip this patch)
(use "git cherry-pick --abort" to cancel the cherry-pick operation)
Changes to be committed:
modified: fe/fe-core/src/main/java/com/starrocks/common/Config.java
modified: fe/fe-core/src/main/java/com/starrocks/connector/ConnectorPartitionTraits.java
modified: fe/fe-core/src/main/java/com/starrocks/connector/partitiontraits/CachedPartitionTraits.java
modified: fe/fe-core/src/main/java/com/starrocks/connector/partitiontraits/DeltaLakePartitionTraits.java
modified: fe/fe-core/src/main/java/com/starrocks/connector/partitiontraits/HivePartitionTraits.java
modified: fe/fe-core/src/main/java/com/starrocks/connector/partitiontraits/HudiPartitionTraits.java
modified: fe/fe-core/src/main/java/com/starrocks/connector/partitiontraits/IcebergPartitionTraits.java
modified: fe/fe-core/src/main/java/com/starrocks/connector/partitiontraits/JDBCPartitionTraits.java
modified: fe/fe-core/src/main/java/com/starrocks/connector/partitiontraits/OlapPartitionTraits.java
modified: fe/fe-core/src/main/java/com/starrocks/scheduler/TableSnapshotInfo.java
Unmerged paths:
(use "git add/rm <file>..." as appropriate to mark resolution)
deleted by us: fe/fe-core/src/main/java/com/starrocks/connector/partitiontraits/KuduPartitionTraits.java
deleted by us: fe/fe-core/src/main/java/com/starrocks/connector/partitiontraits/PaimonPartitionTraits.java
both modified: fe/fe-core/src/main/java/com/starrocks/load/LoadJobWithWarehouse.java
both modified: fe/fe-core/src/main/java/com/starrocks/scheduler/PartitionBasedMvRefreshProcessor.java
both modified: fe/fe-core/src/main/java/com/starrocks/sql/optimizer/MvRewritePreprocessor.java
both modified: fe/fe-core/src/main/java/com/starrocks/sql/optimizer/Optimizer.java
deleted by us: fe/fe-core/src/test/java/com/starrocks/connector/ConnectorPartitionTraitsTest.java
deleted by us: fe/fe-core/src/test/java/com/starrocks/scheduler/PartitionBasedMvRefreshProcessorIcebergTest.java
To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally
@mergify[bot]: Backport conflict, please reslove the conflict and resubmit the pr
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.
Failed conditions
E Maintainability Rating on New Code (required ≥ A)
D Reliability Rating on New Code (required ≥ A)
See analysis details on SonarCloud
Catch issues before they fail your Quality Gate with our IDE extension SonarLint
Why I'm doing:
Fixes #issue https://github.com/StarRocks/StarRocksTest/issues/7940 https://github.com/StarRocks/StarRocksTest/issues/7946 https://github.com/StarRocks/StarRocksTest/issues/7944
What I'm doing:
isSupportPCTRefresh
api for each ConnectorPartitionTraits and use it to decide whether the table type can support pct refresh;enable_mv_query_context_cache
to control whether to use mv query context to avoid bad cases, (true by default)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:
This is an automatic backport of pull request #47628 done by Mergify.
Why I'm doing:
Fixes #issue https://github.com/StarRocks/StarRocksTest/issues/7940 https://github.com/StarRocks/StarRocksTest/issues/7946 https://github.com/StarRocks/StarRocksTest/issues/7944
What I'm doing:
isSupportPCTRefresh
api for each ConnectorPartitionTraits and use it to decide whether the table type can support pct refresh;enable_mv_query_context_cache
to control whether to use mv query context to avoid bad cases, (true by default)What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist: