Repository navigation
[clean](plsql) remove plsql - #58700
Merged
Merged
Conversation
morrySnow
requested review from
CalvinKirs,
dataroaring and
morningman
as code owners
December 4, 2025 04:34
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
Contributor
Author
|
run buildall |
Contributor
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
TPC-H: Total hot run time: 35091 ms |
TPC-DS: Total hot run time: 181993 ms |
ClickBench: Total hot run time: 28.49 s |
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
Contributor
FE UT Coverage ReportIncrement line coverage |
Contributor
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
github-actions
Bot
added
the
approved
Contributor
|
PR approved by at least one committer and no changes requested. |
Contributor
|
PR approved by anyone and no changes requested. |
Contributor
FE Regression Coverage ReportIncrement line coverage |
morrySnow
force-pushed
the
remove_plsql
branch
from
December 4, 2025 09:59
58febda to
26cfa7a
Compare
Contributor
Author
|
run buildall |
github-actions
Bot
removed
the
approved
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
TPC-H: Total hot run time: 34489 ms |
TPC-DS: Total hot run time: 179383 ms |
ClickBench: Total hot run time: 28.4 s |
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
Contributor
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
Contributor
FE Regression Coverage ReportIncrement line coverage |
yiguolei
previously approved these changes
Dec 5, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
TPC-H: Total hot run time: 34435 ms |
TPC-DS: Total hot run time: 179993 ms |
ClickBench: Total hot run time: 28.49 s |
Contributor
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
Contributor
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
Contributor
FE Regression Coverage ReportIncrement line coverage |
Contributor
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
Contributor
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
Contributor
FE Regression Coverage ReportIncrement line coverage |
1 similar comment
Contributor
FE Regression Coverage ReportIncrement line coverage |
morningman
approved these changes
Dec 7, 2025
Contributor
|
PR approved by at least one committer and no changes requested. |
github-actions
Bot
added
the
approved
yiguolei
approved these changes
Dec 8, 2025
nagisa-kunhah
pushed a commit
to nagisa-kunhah/doris
that referenced
this pull request
Dec 14, 2025
morrySnow
pushed a commit
that referenced
this pull request
Aug 13, 2026
…iable with MySQL (#66659) ### What problem does this PR solve? Problem Summary: PL/SQL stored procedures were removed in #58700 because the implementation had many bugs. That removal also deleted the `SHOW (PROCEDURE|FUNCTION) STATUS` grammar, the `ShowProcedureStatusCommand`, and the `information_schema.routines` scanner. Clients such as Bytebase send `SHOW FUNCTION STATUS WHERE Db = '...'` during connection/metadata probing, and the unsupported syntax now blocks users from using the database. This PR only restores the SQL entry points so these statements parse and always return empty result sets without errors. The stored procedure functionality itself is NOT restored. Related PR: #58700
wyxxxcat
pushed a commit
to wyxxxcat/doris
that referenced
this pull request
Aug 17, 2026
…iable with MySQL (apache#66659) ### What problem does this PR solve? Problem Summary: PL/SQL stored procedures were removed in apache#58700 because the implementation had many bugs. That removal also deleted the `SHOW (PROCEDURE|FUNCTION) STATUS` grammar, the `ShowProcedureStatusCommand`, and the `information_schema.routines` scanner. Clients such as Bytebase send `SHOW FUNCTION STATUS WHERE Db = '...'` during connection/metadata probing, and the unsupported syntax now blocks users from using the database. This PR only restores the SQL entry points so these statements parse and always return empty result sets without errors. The stored procedure functionality itself is NOT restored. Related PR: apache#58700
This was referenced Sep 4, 2026
vsai12
added a commit
to bytebase/bytebase
that referenced
this pull request
Sep 16, 2026
The StarRocks/Doris driver was copied from the MySQL driver and still runs SHOW FUNCTION STATUS, SHOW PROCEDURE STATUS and SHOW EVENTS on every dump. Neither engine has MySQL routines or events: StarRocks answers the probes with an empty compatibility stub, and Doris returns PL/SQL rows in a layout the MySQL-shaped scan misreads, so the step could only ever succeed when it found nothing. Doris kernels that removed the PL/SQL grammar (SelectDB 4.0.12+/4.1.8+/5.0.5+, apache/doris#58700 on master) reject the first probe outright, which aborted the whole schema sync and left the SQL Editor object browser empty. Remove the routine and event steps and their helpers, the unused sequenceStmtFmt, and the mysqldump flag-list comment. The regression test runs Dump against a scripted server that rejects the probes the way such a kernel does and asserts the dump completes without sending them. BYT-10211 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
d-bytebase
pushed a commit
to bytebase/bytebase
that referenced
this pull request
Sep 16, 2026
…21467) The StarRocks/Doris driver was copied from the MySQL driver and still runs SHOW FUNCTION STATUS, SHOW PROCEDURE STATUS and SHOW EVENTS on every dump. Neither engine has MySQL routines or events: StarRocks answers the probes with an empty compatibility stub, and Doris returns PL/SQL rows in a layout the MySQL-shaped scan misreads, so the step could only ever succeed when it found nothing. Doris kernels that removed the PL/SQL grammar (SelectDB 4.0.12+/4.1.8+/5.0.5+, apache/doris#58700 on master) reject the first probe outright, which aborted the whole schema sync and left the SQL Editor object browser empty. Remove the routine and event steps and their helpers, the unused sequenceStmtFmt, and the mysqldump flag-list comment. The regression test runs Dump against a scripted server that rejects the probes the way such a kernel does and asserts the dump completes without sending them. BYT-10211 Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
morningman
added a commit
to morningman/doris
that referenced
this pull request
Oct 25, 2026
…ebug view ### What problem does this PR solve? Issue Number: None Related PR: apache#69575 Problem Summary: In BDBJE debug mode (enable_bdbje_debug_mode), SHOW PROC '/bdbje/<db>/<journalId>' renders a record through BdbjeJournalDataProcNode, which called getData().toString() without a null check. The readers of retired operation types consume the payload without keeping it, so their data is null: the op 500 tombstone added by this PR, the four PL/SQL operation types retired by apache#58700 (the same Text.readString(in) form) and the payload-less external-catalog operation types. Viewing any of those records failed with a NullPointerException. For op 500 this is a regression of this PR: before it the record failed to read and the row showed "Not Found". BDBTool, the other BDBJE inspection path, already prints a missing payload as null. The proc node now prints the payload with String.valueOf, so such a record shows null as its data. The op 500 tombstone stays the same as apache#58700's and branch-4.x's. Replay and checkpointing never read these payloads and are unaffected. ### Release note None ### Check List (For Author) - Test: Unit Test - BdbjeJournalDataProcNodeTest: an op 500 record and a retired PL/SQL record, in their written form, show their journal ID, operation name, size and null data; a live OP_SAVE_NEXTID record still shows its payload - Legacy415LanceUpgradeTest, BDBDebuggerTest - Behavior changed: No (the debug view no longer fails on these records) - Does this need documentation: No Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
3 of 16 tasks
morningman
added a commit
to morningman/doris
that referenced
this pull request
Oct 26, 2026
### What problem does this PR solve? Issue Number: None Related PR: apache#69575, apache#67235, apache#68781 Problem Summary: The first commit of this PR kept two pieces of metadata of the durable Lance index job framework readable, as branch-4.1 apache#68781 does: edit-log op 500 (OP_LANCE_INDEX_JOB_UPSERT), read and discarded, and the image module lanceIndexJobManager, listed as deprecated. Only builds that carried apache#67235 wrote them, and apache#68781 reverted apache#67235 on branch-4.1 and branch-4.2 before any release: among the release tags only 4.1.5-rc01 has the writer, while 4.1.5 and 4.2.0-rc01 carry just the tombstones. master never had the framework, so it does not need to read this metadata either. This commit removes the op 500 constant, its JournalEntity and EditLog cases and the deprecated-module entry, together with the two tests that pinned them. master treats such metadata as it did before this PR: a journal with op 500 fails with "UNKNOWN Operation Type 500", and an image with the module fails with "Unknown meta module: lanceIndexJobManager" unless ignore_unknown_metadata_module is set. The BdbjeJournalDataProcNode fix stays. master's own retired operation types (the PL/SQL ones of apache#58700 and the payload-less external-catalog ones) are read without keeping a payload, so SHOW PROC '/bdbje/<db>/<journalId>' on such a record failed with a NullPointerException before this PR. Its test now uses only the PL/SQL record. ### Release note None ### Check List (For Author) - Test: Unit Test - Legacy415LanceUpgradeTest (7), LanceGsonCompatReplayTest (4) and BdbjeJournalDataProcNodeTest (2) with 13 related upgrade, GSON and journal suites: 103 tests pass; fe-core checkstyle passes - With getData().toString() back in BdbjeJournalDataProcNode, the PL/SQL record test fails with a NullPointerException - Behavior changed: Yes. Compared with the earlier commits of this PR, a journal with op 500 and an image with the lanceIndexJobManager module are rejected again, as on master. - Does this need documentation: No Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
morningman
added a commit
that referenced
this pull request
Oct 29, 2026
…69575) ### What problem does this PR solve? Issue Number: None Related PR: #65730, #67235, #68781 Problem Summary: **In short.** This PR makes master read the Lance catalogs that branch-4.1 persists (#65730, released in 4.1.4): an FE image written by 4.1.4 or later with a Lance catalog in it now loads. Before this PR the image failed to parse, so a cluster with a Lance catalog could not be upgraded from any released 4.1.4 / 4.1.4.1 / 4.1.5 build (or from 4.2) to a master-based build: the FE did not start. The Lance catalog's GSON labels are mapped to the plugin-driven classes, as the Iceberg, Paimon and LakeSoul labels already are, and the catalog stays registered, unusable until a Lance connector plugin is installed. **Background.** branch-4.1 added a Lance catalog as fe-core classes in #65730 (released in 4.1.4). Like every external catalog, it is persisted in the image's `datasource` module as GSON JSON whose `clazz` field names the class, `LanceExternalCatalog`, with `logType` `LANCE`. master has no Lance classes: external catalogs are served by connector plugins, and the labels of the catalogs that used to be fe-core classes are redirected to `PluginDrivenExternalCatalog` / `PluginDrivenExternalDatabase` / `PluginDrivenMvccExternalTable` by `registerCompatibleSubtype` in `GsonUtils`. A Lance connector plugin does not exist on master yet; it will be ported later. branch-4.1 also had, for a while, a durable Lance index job framework (#67235) that wrote edit-log op 500 (`OP_LANCE_INDEX_JOB_UPSERT`) and an image module named `lanceIndexJobManager`. #68781 reverted it on branch-4.1 and branch-4.2 before any release: among the release tags only 4.1.5-rc01 has the writer, while 4.1.5 and 4.2.0-rc01 keep just a tombstone that reads and discards both. master never had the framework, and this PR does not make it read that metadata either. The upgrade fixtures on master (`upgrade/413`) were generated from 4.1.3, before Lance existed, so no test caught this. **The problem, and what it cost.** Compared on master against fixtures emitted by real 4.1.5 bytecode: | Metadata from a 4.1.4+ FE | master before this PR | after this PR | |---|---|---| | image whose `datasource` module has a Lance catalog (every 4.1.4+ cluster with one) | image fails to parse: `cannot deserialize interface org.apache.doris.datasource.CatalogIf subtype named LanceExternalCatalog; did you forget to register a subtype?`; the FE cannot start | loads; the catalog is a `PluginDrivenExternalCatalog` of type `lance` with all its properties, comment and auto-analyze policies; using it fails with `No ConnectorProvider found for plugin-driven catalog: <name>, type: lance. Ensure the connector plugin is installed.` | | `OP_CREATE_CATALOG` of a Lance catalog | replays as a degraded catalog (the entry carries only properties) | unchanged | The only labels in the GSON registries of 4.1.4.1, 4.1.5 and 4.2.0-rc01 that master does not know are `LanceExternalCatalog`, `LanceExternalDatabase` and `LanceExternalTable`. **How this PR fixes it.** - `GsonUtils`: `LanceExternalCatalog` → `PluginDrivenExternalCatalog`, `LanceExternalDatabase` → `PluginDrivenExternalDatabase`, `LanceExternalTable` → `PluginDrivenMvccExternalTable` (`LanceExternalTable` implemented `MvccTable`). 4.1.x never persists an external database or table, so only the catalog label can actually appear; the other two complete the registry, as for the other migrated connectors. - `InitCatalogLog.Type` keeps `LANCE`, so the `logType` 4.1.4+ wrote still deserializes to itself. Nothing depends on it: a Lance catalog always persists its `type` property (no resource type creates one), and `PluginDrivenExternalCatalog#gsonPostProcess` rewrites the logType to `PLUGIN`. - `BdbjeJournalDataProcNode`, which renders `SHOW PROC '/bdbje/<db>/<journalId>'` in BDBJE debug mode, prints a record read without a payload as `null`, as `BDBTool` already does, instead of failing with a `NullPointerException`. This is an existing master issue that came up in review, not a Lance one: the readers of the retired operation types already on master (the PL/SQL ones of #58700 and the external-catalog ones) keep no payload. Until a Lance connector plugin is installed, an upgraded cluster lists its Lance catalogs and fails only when one is used; installing the plugin makes them work without any metadata change, since the catalog properties are handed to the connector unchanged. **Results.** - New golden fixtures `fe/fe-core/src/test/resources/upgrade/415/`, emitted by 4.1.5-release bytecode like `upgrade/413` (generator and `PROVENANCE.txt` included, byte-deterministic): the `datasource` module with three Lance catalogs (filesystem on S3, filesystem on `file://`, REST with bearer auth), their `OP_CREATE_CATALOG` entries, and 4.1.5's label registries. - `Legacy415LanceUpgradeTest` (7 tests): the image loads and every Lance catalog becomes a `PluginDrivenExternalCatalog` of type `lance` with the `PLUGIN` logType; every persisted property, the comment, `lastUpdateTime` and the auto-analyze policy survive; the persisted logType names still deserialize; without a plugin the catalog fails only when used, with the message above; a provider claiming `lance` receives exactly the persisted properties, from the image and from the journal; the journal entries replay with and without a plugin. - `LanceGsonCompatReplayTest` (4 tests): the three labels replay as the expected classes (the table as the MVCC variant), and they are the only labels 4.1.5 registered beyond 4.1.3. - Each of these changes, undone on its own, turns tests red: dropping the catalog label (5 tests, with the parse error above), the database label, mapping the table label to the non-MVCC class, or removing `LANCE`. - `BdbjeJournalDataProcNodeTest` (2 tests): a retired PL/SQL record, in its written form, shows its journal ID, operation name, size and `null` data in the debug view; a live `OP_SAVE_NEXTID` record still shows its payload. With `getData().toString()` back, the first test fails with a `NullPointerException`. - The three classes above with 13 related upgrade, GSON and journal suites (`Legacy413ImageMigrationTest`, `*GsonCompatReplayTest`, `LegacyExternalTableTypeReplayTest`, `CatalogMgrTest`, `ExternalCatalogTest`, `ConstraintPersistTest`, `BDBJEJournalTest`, `BDBToolTest`, `BDBDebuggerTest`, ...): 103 tests pass; fe-core checkstyle passes. Co-authored-by: kid <lucian1412@outlook.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
related PR: #30817 #31574 #32866
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)