Skip to content

fix(mysql): Work around for Issue #2206 (ColumnNotFound error when querying)#4086

Open
duelafn wants to merge 1 commit intolaunchbadge:mainfrom
duelafn:bug-2206
Open

fix(mysql): Work around for Issue #2206 (ColumnNotFound error when querying)#4086
duelafn wants to merge 1 commit intolaunchbadge:mainfrom
duelafn:bug-2206

Conversation

@duelafn
Copy link

@duelafn duelafn commented Nov 3, 2025

This fixes the test case in #2206 (comment).

I realize that this may not be the best fix for the issue, so consider this a conversation starter PR. The comments in the mysql connection/executor.rs suggest that column information may be delayed until first result, but where and how exactly that is supposed to happen wasn't clear to me and the column information is not currently being updated appropriately. This patch catches such situations and compensates. A better fix would find where the update should have happend -- I just don't know where or how to do that.

Does your PR solve an issue?

fixes #2206

Is this a breaking change?

This change may cause some code which previously returned Err(ColumnNotFound) to now return Ok(value). This is a bug fix so the user code expected to receive Ok(value) but this is technically a change in behavior.

@duelafn duelafn force-pushed the bug-2206 branch 3 times, most recently from 794a3e0 to f85a70c Compare November 4, 2025 15:44
Comment on lines 657 to 658
// Support for RETURNING added in MariaDB 10.5.0 and not currently (2025)
// supported in MySQL. Don't fail test due to lack of RETURNING support.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can actually just add #[cfg(mariadb)] to the test to only run it on MariaDB.

Comment on lines 45 to 48
// Work around Issue #2206, <https://github.com/launchbadge/sqlx/issues/2206>
//
// column_names is empty so will always fail, but user expects this to work.
// Check the individual columns.
Copy link
Collaborator

@abonander abonander Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually fixing this shouldn't be that much more complex, I have some more context in #1530 (comment) which I suspect is the same issue (albeit with maybe a different cause).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The response from the MariaDB maintainers was to just always prefer the metadata returned with the actual result-set: https://jira.mariadb.org/browse/MDEV-27013?focusedCommentId=301657&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-301657

MariaDB may change the column info between PREPARE and EXECUTE if the schema changes
(https://jira.mariadb.org/browse/MDEV-27013). Therefore, always read column info from
the execute metadata and use it for the row column_names field. Fixes: launchbadge#2206, launchbadge#1530
@duelafn
Copy link
Author

duelafn commented Feb 6, 2026

Hello, thanks for the review. I'm not entirely clear on what changes you are proposing, but as a guess I've updated the pull request to ignore column_names from the PREPARE and always re-read the metadata during EXECUTE as recommended by mariadb.

This does open the sitution that ColumnIndex<MySqlStatement>::index() and ColumnIndex<MySqlRow>::index() may return different results, though this seems reasonable as this is what the database actually returned.

@duelafn duelafn requested a review from abonander February 6, 2026 17:28
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.

ColumnNotFound error when querying with MySQL

2 participants