Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

MySQL: time and chrono type tests are broken by MySQL server 8.0.28 #1664

Open
abonander opened this issue Feb 1, 2022 · 6 comments
Open

MySQL: time and chrono type tests are broken by MySQL server 8.0.28 #1664

abonander opened this issue Feb 1, 2022 · 6 comments
Labels
bug:db Involves a bug in the database server db:mysql Related to MySQL

Comments

@abonander
Copy link
Collaborator

abonander commented Feb 1, 2022 •
edited

I've figured out why CI is failing for MySQL.

For some reason, in the newest version of MySQL (8.0.28), for SELECT ? when a TIME, DATE, DATETIME or TIMESTAMP type is bound,
the Binary Resultset packet reports that the column has a type of MYSQL_TYPE_VAR_STRING.

They mention some changes to date/time type handling in their changelog which I strongly believe is relevant: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-28.html#mysqld-8-0-28-data-types

(And coincidentally acknowledge the breakage from 8.0.27 I previously had to fix here:

sqlx/sqlx-test/src/lib.rs

Lines 200 to 201 in 2182925

// MySQL 8.0.27 changed `<=>` to return an unsigned integer
"SELECT CAST({0} <=> ? AS SIGNED INTEGER), {0}, ?"
)

Question is, do we just fix this in the type tests or report this as a database bug, or both?
@abonander abonander added db:mysql Related to MySQL bug:db Involves a bug in the database server labels Feb 1, 2022
@abonander
Copy link
Collaborator Author

Submitted MySQL bug: https://bugs.mysql.com/bug.php?id=106352

@abonander
Copy link
Collaborator Author

abonander commented Feb 11, 2022 •
edited

Update: fix coming in 8.0.29! (See conversation in link above)

@abonander
Copy link
Collaborator Author

I've fixed CI for now by pinning the version at 8.0.27:

sqlx/tests/docker-compose.yml

Lines 10 to 11 in 7fd324d

# FIXME: 8.0.28 introduced a regression in our type tests: https://github.com/launchbadge/sqlx/issues/1664
# The MySQL devs agreed that it was a regression and that it will be fixed in 8.0.29

@hollow-owl
Copy link

This also happens on mariadb Ver 15.1 Distriib 10.7.3-MariaDB

grooverdan added a commit to grooverdan/sqlx that referenced this issue Sep 8, 2023
@grooverdan
Bump mariadb CI images + mysql unpin
4cb2987 
With MariaDB 10.3 EOL it seems prudent to include
the latest 10.11 LTS release in the CI tests.

To catch launchbadge#1664 sort of issues prior to release, add
a container image test for mariadb that contains the
finished pre-release code changes (and container changes)
to ensure that compatibilty is maintianed. When
server code hits the branch associated with this tag
it is considered finished by its server developers and
has passes CI so no regressions are expected, but
it wouldn't hurt to have CI in other systems testing
it too.

Since MySQL has fixed the regression that caused launchbadge#1664
this puts it back to their 8.0 release tag.

Append the :z tag to the docker compose volume mounts
so on selinux systems enough permissions occur for the
volume to be able to read the volume contents.
@grooverdan grooverdan mentioned this issue Sep 8, 2023
Merged
@grooverdan
Copy link
Contributor

@hollow-owl did the MariaDB get resolved? Its not merged from MySQL and I couldn't find a MariaDB bug. We'll see with #2739 I guess.

grooverdan added a commit to grooverdan/sqlx that referenced this issue Sep 8, 2023
@grooverdan
Bump mariadb CI images + mysql unpin
34416a5 
With MariaDB 10.3 EOL it seems prudent to include
the latest 10.11 LTS release in the CI tests.

To catch launchbadge#1664 sort of issues prior to release, add
a container image test for mariadb that contains the
finished pre-release code changes (and container changes)
to ensure that compatibilty is maintianed. When
server code hits the branch associated with this tag
it is considered finished by its server developers and
has passes CI so no regressions are expected, but
it wouldn't hurt to have CI in other systems testing
it too.

Since MySQL has fixed the regression that caused launchbadge#1664
this puts it back to their 8.0 release tag.

Append the :z tag to the docker compose volume mounts
so on selinux systems enough permissions occur for the
volume to be able to read the volume contents.
@grooverdan
Copy link
Contributor

On MariaDB we ported MySQL's test case and we aren't affected (MariaDB/server#2752).

Also when a TIMESTAMP is bound a TIMESTAMP is returned.

abonander pushed a commit that referenced this issue Sep 12, 2023
@grooverdan
Bump mariadb CI images + mysql unpin (#2739)
a6a2af1 
With MariaDB 10.3 EOL it seems prudent to include
the latest 10.11 LTS release in the CI tests.

To catch #1664 sort of issues prior to release, add
a container image test for mariadb that contains the
finished pre-release code changes (and container changes)
to ensure that compatibilty is maintianed. When
server code hits the branch associated with this tag
it is considered finished by its server developers and
has passes CI so no regressions are expected, but
it wouldn't hurt to have CI in other systems testing
it too.

Since MySQL has fixed the regression that caused #1664
this puts it back to their 8.0 release tag.

Append the :z tag to the docker compose volume mounts
so on selinux systems enough permissions occur for the
volume to be able to read the volume contents.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug:db Involves a bug in the database server db:mysql Related to MySQL
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@grooverdan @abonander @hollow-owl