fix(mysql): Work around for Issue #2206 (ColumnNotFound error when querying)#4086
fix(mysql): Work around for Issue #2206 (ColumnNotFound error when querying)#4086duelafn wants to merge 1 commit intolaunchbadge:mainfrom
Conversation
794a3e0 to
f85a70c
Compare
tests/mysql/mysql.rs
Outdated
| // 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. |
There was a problem hiding this comment.
You can actually just add #[cfg(mariadb)] to the test to only run it on MariaDB.
sqlx-mysql/src/row.rs
Outdated
| // 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. |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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
|
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 This does open the sitution that |
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.rssuggest 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 returnOk(value). This is a bug fix so the user code expected to receiveOk(value)but this is technically a change in behavior.