fix: MySQL introspection failing on MariaDB servers#1547
Conversation
Studio's tables introspection aggregated column metadata with json_arrayagg, which does not exist before MariaDB 10.5 (#1511) and returns LONGTEXT rather than native JSON on any MariaDB version, while cast(... as json) is invalid syntax there (#1367). The MySQL adapter now detects the server flavor once per adapter via select version() and, on MariaDB, aggregates columns with coalesce(concat('[', group_concat(json_object(...) separator ','), ']'), '[]') instead. String-aggregated columns payloads are parsed back into arrays on the client, which also hardens introspection against MySQL transports that return json_arrayagg results as strings. Version detection failures fall back to the existing MySQL SQL. Verified end-to-end against MariaDB 10.4 and 10.11 containers and the Vitess-backed MySQL integration suite. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 35 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (5)
WalkthroughThe MySQL adapter now queries 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
|
Compute preview deployed. Branch: |
There was a problem hiding this comment.
Warning
CodeRabbit couldn't request changes on this pull request because it doesn't have sufficient GitHub permissions.
Please grant CodeRabbit Pull requests: Read and write permission and re-run the review.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@data/mysql-core/introspection.ts`:
- Around line 172-179: The MariaDB branch in the aggregated query must not use
group_concat, because group_concat_max_len can truncate column metadata. Replace
this aggregation with a non-truncating path that returns one row per column and
groups results client-side, or an equivalent approach independent of the session
cap, while preserving normalizeTablesQueryResult behavior. Add a regression test
covering a metadata payload larger than the default 1 MB limit.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 0496bcf5-f900-4973-a8e5-4c087ef75d75
📒 Files selected for processing (5)
.changeset/mariadb-introspection-compat.mdFEATURES.mddata/mysql-core/adapter.tsdata/mysql-core/introspection.mariadb.test.tsdata/mysql-core/introspection.ts
Addresses PR review feedback: the group_concat-based aggregation was capped by the session's group_concat_max_len (1MB default on MariaDB, sometimes configured much lower), which could silently truncate the JSON payload on very wide tables. The MariaDB flavor now uses a dedicated tables query (getMariaDBTablesQuery) that returns one row per column with no JSON functions and no aggregation at all, and groupMariaDBTablesQueryResult groups the rows into the aggregated shape on the client. This is immune to any aggregation size cap and works on every MariaDB version. The MySQL tables query is restored to its original json_arrayagg form. Includes a regression test grouping over 1MB of column metadata, and was verified against MariaDB 10.4/10.11 containers including with group_concat_max_len lowered to 128 bytes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Fixes #1367, fixes #1511
Root cause
The tables-introspection query aggregates column metadata with
cast(coalesce(json_arrayagg(json_object(...)), '[]') as json). This breaks on MariaDB two ways:json_arrayaggat all (prisma studio error: FUNCTION pomagamy.json_arrayagg does not exist #1511,FUNCTION json_arrayagg does not exist)cast(... as json)is a syntax error on every version (Support MariaDB. #1367)Fix
select version()(matchesMariaDBcase-insensitively, incl.5.5.5-…-MariaDBprefixed strings; detection failure falls back to the MySQL SQL).coalesce(concat('[', group_concat(json_object(...) separator ','), ']'), '[]')— valid on all supported MariaDB versions.normalizeTablesQueryResult()parses stringcolumnspayloads for all flavors (transport-agnostic; equivalent to the JS-side hardening proposed in fix mysql introspection json columns #1495, which this supersedes at the SQL level).Verification
pnpm test:data:mysqlagainst local Vitess/MySQL: 38/38 pass — the MySQL SQL path is byte-identical (snapshot-asserted).🤖 Generated with Claude Code