fix(mysql): read Doris's real build from @@version_comment - #576
Merged
Conversation
Apache Doris answers VERSION() with a fixed, fictitious MySQL
compatibility number (5.7.99) and has no current_version() to fall
back to, so the overview showed a vendor-less "MySQL 5.7.99" for
every Doris connection. Doris does put its own build string in
@@version_comment ("doris version doris-4.1.3-rc02-7126cf65d96"),
which getOverview() now reads in the same query as VERSION() and
labelServerVersion() now prefers when the version_comment matches
that shape, showing "Apache Doris 4.1.3-rc02-7126cf65d96" instead.
Real MySQL's own version_comment ("MySQL Community Server - GPL")
and MariaDB's ("mariadb.org binary distribution") do not match the
Doris pattern, and MariaDB/TiDB/Vitess/OceanBase already
self-identify through VERSION() before version_comment is even
checked, so none of those change. Verified live against a fresh
apache/doris:all-in-one-4.1.3, a fresh starrocks/allin1-ubuntu:3.3
(the fork this shares a code path with, version_comment answers its
own build number and does not match either), plain MySQL 26.7.0 and
MariaDB 12.3.2.
Updated the caveat text in compatibility.ts, docs/providers/README.md
and docs/providers/mysql.md that described the old, unread behavior
as permanent.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
cevheri
approved these changes
Sep 5, 2026
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
2 participants
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.
Description
Apache Doris answers
VERSION()with a fixed, fictitious MySQL compatibility number (5.7.99) and has nocurrent_version()to fall back to, so the overview showed a vendor-less "MySQL 5.7.99" for every Doris connection. Doris does put its own build string in@@version_comment("doris version doris-4.1.3-rc02-7126cf65d96"), whichgetOverview()now reads in the same query asVERSION(), andlabelServerVersion()now prefers that string when it matches Doris's shape, showing"Apache Doris 4.1.3-rc02-7126cf65d96"instead.Type of Change
Related Issue
No linked issue. Found while preparing the Apache Doris vendor-listing docs, and scoped narrowly enough to fix directly rather than file first.
Changes Made
src/lib/db/providers/sql/mysql.ts:getOverview()'s existingSELECT VERSION()now also selects@@version_commentin the same query (no new round trip). AddedDORIS_VERSION_COMMENTand extendedlabelServerVersion()to prefer the parsed Doris build string whenVERSION()does not already self-identify (matching the existing MariaDB/TiDB/Vitess/OceanBase path) andversion_commentmatches Doris's"doris version ..."shape.src/lib/db/compatibility.ts,docs/providers/README.mdanddocs/providers/mysql.mdthat described the old, unread@@version_commentbehavior as permanent.tests/integration/db/mysql-provider.test.tsfor the Doris label and for a genericversion_comment(real MySQL's own) not being mistaken for Doris's, and updatedtests/unit/db/compatibility.test.tsto match the corrected caveats.Testing
Test Environment
Screenshots (if applicable)
None attached, no UI change. Verified by connecting to live containers and reading
@@version_commentdirectly, and throughgetOverview()'s query; the exact readings are under Additional Notes.Checklist
Additional Notes
Ran
bun run format,lint,typecheck, and the full test suite locally. 10531/10532 pass; the one failure (tests/unit/db/sqlite-driver.test.ts, "No such built-in module: node:sqlite") reproduces identically on a cleanmaincheckout with no changes, confirmed withgit stash, unrelated to this change.mysql.tsitself shows 100 percent line and function coverage from its own test file in isolation.Live verification against fresh containers, direct SQL and through the provider:
apache/doris:all-in-one-4.1.3):SELECT VERSION(), @@version_commentreturns5.7.99/doris version doris-4.1.3-rc02-7126cf65d96; overview now readsApache Doris 4.1.3-rc02-7126cf65d96.starrocks/allin1-ubuntu:3.3-latest, fresh container, the fork this shares the code path with):version_commentanswers its own build,3.3.22-753696f, which does not match the Doris pattern; overview is unchanged, stillMySQL 5.1.0.mysql:latest, 26.7.0):version_commentanswersMySQL Community Server - GPL, does not match; unchanged.mariadb:12.3, 12.3.2): already self-identifies throughVERSION()beforeversion_commentis checked at all; unchanged.