fix(mariadb): match JSON column metadata by column instead of attribute position by WikiRik · Pull Request #18329 · sequelize/sequelize · GitHub
Skip to content

fix(mariadb): match JSON column metadata by column instead of attribute position - #18329

Open
WikiRik wants to merge 2 commits into
WikiRik/deps-lockfile-refreshfrom
WikiRik/mariadb-json-column-metadata
Open

fix(mariadb): match JSON column metadata by column instead of attribute position#18329
WikiRik wants to merge 2 commits into
WikiRik/deps-lockfile-refreshfrom
WikiRik/mariadb-json-column-metadata

Conversation

@WikiRik

@WikiRik WikiRik commented Sep 3, 2026

Copy link
Copy Markdown
Member

Pull Request Checklist

  • Have you added new tests to prevent regressions?
  • If a documentation update is necessary, have you opened a PR to the documentation repository?
  • Did you update the typescript typings accordingly (if applicable)?
  • Does the description below contain a link to an existing issue or a description of the issue you are solving?
  • Does the name of your PR follow our conventions?

Description of Changes

Stacked on #18328 (needs mariadb >= 3.5.0, see below).

The bug

handleJsonSelectQuery walked the model's JSON attributes and the result set's column metadata with the same index:

for (const [i, _field] of Object.keys(this.model.fieldRawAttributesMap).entries()) {
  // ...
  (!meta[i] || meta[i].dataTypeFormat !== 'json')

The metadata follows the order of the SELECT clause, 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 by orgTable() so an include cannot 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 turns mariadb latest green 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#map whose result was assigned to a local and then dropped, so only the in-place mutation ever had an effect. The DataTypes.JSON.parse branch inside it was dead — that static does not exist (verified at runtime: typeof DataTypes.JSON.parse === 'undefined'). Had it ever been defined, the map would 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. handleJsonSelectQuery is marked @internal so it stays out of the generated API docs.

Tests

packages/mariadb/src/query.test.ts covers 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

@coderabbitai

coderabbitai Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

@WikiRik
WikiRik force-pushed the WikiRik/mariadb-json-column-metadata branch from 7c80e12 to 8386387 Compare September 3, 2026 12:47
@WikiRik
WikiRik force-pushed the WikiRik/mariadb-json-column-metadata branch from 8386387 to 49fb0da Compare September 3, 2026 13:13
@WikiRik
WikiRik force-pushed the WikiRik/mariadb-json-column-metadata branch from 49fb0da to da0274d Compare September 3, 2026 13:18
…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
WikiRik force-pushed the WikiRik/mariadb-json-column-metadata branch from da0274d to ba6365d Compare September 3, 2026 17:53
Comment thread packages/mariadb/src/query.test.ts Outdated
Comment thread packages/mariadb/src/query.test.ts Outdated
Comment thread packages/mariadb/src/query.test.ts Outdated
Comment thread packages/mariadb/src/query.test.ts Outdated
Comment thread packages/mariadb/src/query.test.ts Outdated
Comment thread packages/mariadb/src/query.js Outdated
Comment thread packages/mariadb/src/query.js Outdated
Comment thread packages/mariadb/src/query.js Outdated
Co-authored-by: Rik Smale <13023439+WikiRik@users.noreply.github.com>
@WikiRik
WikiRik marked this pull request as ready for review September 3, 2026 20:14
@WikiRik
WikiRik requested a review from a team as a code owner September 3, 2026 20:14
@WikiRik
WikiRik requested review from SippieCup and sdepold September 3, 2026 20:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant