{{ message }}
fix(mariadb): match JSON column metadata by column instead of attribute position - #18329
Open
WikiRik wants to merge 2 commits into
Open
fix(mariadb): match JSON column metadata by column instead of attribute position#18329WikiRik wants to merge 2 commits into
WikiRik wants to merge 2 commits into
Conversation
Contributor
5 tasks
WikiRik
force-pushed
the
WikiRik/mariadb-json-column-metadata
branch
from
September 3, 2026 12:47
7c80e12 to
8386387
Compare
WikiRik
force-pushed
the
WikiRik/mariadb-json-column-metadata
branch
from
September 3, 2026 13:13
8386387 to
49fb0da
Compare
WikiRik
force-pushed
the
WikiRik/mariadb-json-column-metadata
branch
from
September 3, 2026 13:18
49fb0da to
da0274d
Compare
…te position `handleJsonSelectQuery` walked the model's JSON attributes and the result set's column metadata with the same index. The metadata follows the order of the SELECT clause, which has no relation to the order of the model's attributes, so a model with more than one JSON attribute read the wrong column's metadata and either skipped decoding a value it should have decoded or tried to decode one the driver had already decoded. Match the metadata by column instead. `name()` is the alias the column has in the result set, which is what the row is keyed by, so it is the only unambiguous match; `orgName()` is only a fallback for aliased columns, and is qualified by `orgTable()` so an `include` cannot match a same-named column of a joined table. Read the extended type through the driver's public `isDataTypeFormatJson()` rather than the private `_dataTypeFormat` field. This needs mariadb >= 3.5.0, which is where that method was added. The rows were also being run through `Array#map` whose result was assigned to a local and then dropped, so only the in-place mutation ever had an effect, and the `DataTypes.JSON.parse` branch inside it was dead: that static does not exist. Had it existed, the map would have replaced each row with a single parsed field value. Decode in place instead, and hoist the loop-invariant metadata check out of the row loop. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EgPPfqYYk6PFGbanp5mAFh
WikiRik
force-pushed
the
WikiRik/mariadb-json-column-metadata
branch
from
September 3, 2026 17:53
da0274d to
ba6365d
Compare
5 tasks
WikiRik
commented
Sep 3, 2026
Co-authored-by: Rik Smale <13023439+WikiRik@users.noreply.github.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.

Pull Request Checklist
Description of Changes
Stacked on #18328 (needs
mariadb >= 3.5.0, see below).The bug
handleJsonSelectQuerywalked the model's JSON attributes and the result set's column metadata with the same index:The metadata follows the order of the
SELECTclause, which has no relation to the order of the model's attributes. Any model with more than one JSON attribute could therefore read the wrong column's metadata and either skip decoding a value it should have decoded, or try to decode one the driver had already decoded.The fix
Match the metadata by column instead:
name()is the alias the column has in the result set, which is what the row is keyed by, so it is the only unambiguous match.orgName()is only a fallback for aliased columns, and is qualified byorgTable()so anincludecannot match a same-named column of a joined table.The migration to the driver's public
isDataTypeFormatJson()accessor is not part of this PR — that is dependency catch-up for the mariadb 3.5 bump and lives in #18328, which is also what turnsmariadb latestgreen there. This PR is only the matching bug, which is pre-existing and independent of the driver version.Cleanup included
The rows were being run through
Array#mapwhose result was assigned to a local and then dropped, so only the in-place mutation ever had an effect. TheDataTypes.JSON.parsebranch inside it was dead — that static does not exist (verified at runtime:typeof DataTypes.JSON.parse === 'undefined'). Had it ever been defined, themapwould have replaced each row with a single parsed field value.Decoding now happens in place, and the loop-invariant metadata check is hoisted out of the row loop.
handleJsonSelectQueryis marked@internalso it stays out of the generated API docs.Tests
packages/mariadb/src/query.test.tscovers metadata matched by column rather than by attribute position, the json-format guard, the aliased-column fallback and its table qualification, the no-metadata case, and non-model queries. 10 tests, all passing.🤖 Generated with Claude Code
https://claude.ai/code/session_01EgPPfqYYk6PFGbanp5mAFh