[Bug] Is MariaDB new default collation `utf8mb4_uca1400_ai_ci` breaking the `sea-orm-cli generate`?

[libsilverwolf]

Description

I can't use the entity generator with my MariaDB instance deployed by docker.

MariaDB version: 11.3.2-MariaDB-1:11.3.2+maria~ubu2204

https://github.com/MariaDB/mariadb-docker/issues/591 Seems they has been changed the default collation from utf8mb4_general_ci.

Steps to Reproduce

1. cargo install sea-orm-cli --git https://github.com/SeaQL/sea-orm
2. Create tables for testing

create database sea_bug;
use sea_bug;
create table sea_bug.test (
	name varchar(100) not null
) engine=InnoDB default charset=utf8mb4 COLLATE=utf8mb4_uca1400_ai_ci;

4. Try generating entities

$ RUST_BACKTRACE=1 sea-orm-cli generate entity -u mysql://mariadb:3306/sea_bug -o entity/src -v

Expected Behavior

Generating entities normally.

Actual Behavior

Connecting to MySQL ...
2024-12-10T06:58:57.579824Z DEBUG sqlx_mysql::connection::tls: not performing TLS upgrade: unsupported by server
2024-12-10T06:58:57.761834Z DEBUG sqlx::query: summary="SET sql_mode=(SELECT CONCAT(@@sql_mode, ',PIPES_AS_CONCAT,NO_ENGINE_SUBSTITUTION')),time_zone='+00:00',NAMES …" db.statement="\n\nSET\n  sql_mode =(\n    SELECT\n      CONCAT(\n        @ @sql_mode,\n        ',PIPES_AS_CONCAT,NO_ENGINE_SUBSTITUTION'\n      )\n  ),\n  time_zone = '+00:00',\n  NAMES utf8mb4 COLLATE utf8mb4_unicode_ci;\n" rows_affected=0 rows_returned=0 elapsed=91.129982ms elapsed_secs=0.091129982
Discovering schema ...
2024-12-10T06:58:58.034378Z DEBUG sqlx::query: summary="SELECT version()" db.statement="" rows_affected=0 rows_returned=1 elapsed=181.293449ms elapsed_secs=0.181293449
2024-12-10T06:58:58.399831Z DEBUG sqlx::query: summary="SELECT `table_name`, `engine`, `auto_increment`, …" db.statement="\n\nSELECT\n  `table_name`,\n  `engine`,\n  `auto_increment`,\n  `table_collation`,\n  `table_comment`,\n  `create_options`,\n  `collation_character_set_applicability`.`character_set_name`\nFROM\n  `information_schema`.`tables`\n  LEFT JOIN `information_schema`.`collation_character_set_applicability` ON `collation_character_set_applicability`.`collation_name` = `tables`.`table_collation`\nWHERE\n  `table_schema` = ?\n  AND `table_type` IN (?, ?)\nORDER BY\n  `table_name` ASC\n" rows_affected=0 rows_returned=1 elapsed=183.678072ms elapsed_secs=0.183678072
thread 'main' panicked at /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sqlx-core-0.8.2/src/row.rs:72:37:
called `Result::unwrap()` on an `Err` value: ColumnDecode { index: "6", source: UnexpectedNullError }
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: <sqlx_mysql::row::MySqlRow as sea_schema::mysql::discovery::executor::real::GetMySqlValue>::get_string
   4: <sea_schema::mysql::query::table::TableQueryResult as core::convert::From<&sqlx_mysql::row::MySqlRow>>::from
   5: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
   6: sea_orm_cli::commands::generate::run_generate_command::{{closure}}
   7: <async_std::task::builder::SupportTaskLocals<F> as core::future::future::Future>::poll
   8: <futures_lite::future::Or<F1,F2> as core::future::future::Future>::poll
   9: async_io::driver::block_on
  10: async_global_executor::reactor::block_on
  11: async_std::task::builder::Builder::blocking
  12: sea_orm_cli::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Reproduces How Often

See above.

Workarounds

Change the collation of table from utf8mb4_uca1400_ai_ci to utf8mb4_general_ci ?

Reproducible Example

See above.

Versions

├── sea-orm v1.1.2
│   ├── sea-orm-macros v1.1.2 (proc-macro)
│   │   ├── sea-bae v0.2.1 (proc-macro)
│   ├── sea-query v0.32.1
│   ├── sea-query-binder v0.7.0
│   │   ├── sea-query v0.32.1 (*)

[Cai-z-us]

I encountered the same problem. Did you solve it？

[wling-art]

same

[tyt2y3]

it appears to be collation related. seems like collation_character_set_applicability is null, because it coulnd't be joined with table_collation. at the end we only want to know the character set. an ugly workaround would be recognize the prefix utf8mb4_, but there must a more proper way of querying this info