Breaking MySQL issue after migration to v6.0.0+ - what's the "expression" field?

[JonasDoe]

Hey, I cannot find anything about the breaking issue I'm facing with upgrading to v6 (coming from v5.9.8), so I hope somebody here has some head up for me:
My issue is that after the migration invokiing ISchemaGenerator.ISchemaGenerator (for MySQL in my case) leads to this error:

DB schema couldn't get upgraded: Error: select table_name as table_name, nullif(table_schema, schema()) as schema_name, index_name as index_name, non_unique as non_unique, column_name as column_name, expression as expression
        frommywhere table_schema = database()
        and table_name in (...) 
       order by schema_name, table_name, index_name, seq_in_index - Unknown column 'expression' in 'field list'"}

As background, I'm using MariaDB.
The error seems appropriate - "information_schema.statistics.expression" isn't a column which I can see in our table, and it's neither documented in the MariaDB nor the MySQL 5.7 docs. (oddly enough, it's mentioned in the documentation there nevertheless ... probably a copy-paste error from MySQL 8.0.)
In MySQL 8.0 it exists, at least there's an entry for it.

I doubt I'ld the first person using the MySQL connector since the major version upgrade. Does anybody have an idea where this all of the sudden is could come from? Do I have to specify MySQL 5.7-compatiblity at some place?
Thanks in advance!

[JonasDoe]

Oh, for some reason I did not find this issue the first time I was looking for it. That explains everything. :/

[B4nan]

You could always patch the ORM dynamically, e.g. in the ORM config which you can be sure will be evaluated before any schema generator related stuff (or create a custom driver to override the schema helper implementation) if upgrading MySQL would be problematic for you. I would also accept a PR that handles this gracefully somehow.

[JonasDoe]

@B4nan: Thanks for your suggestions! I'm not sure how well upgrading would work. It doesn't seems like MariaDB features this column at the moment: https://mariadb.com/kb/en/information-schema-statistics-table, so I think I'm stuck with mikro-orm v5 for now. Aslo, MySQL v5.7 might also offers better compatibility with TiDB or Vitess, options we consider to switch to later on, so I'm on the fence.
Maybe its best if I will try to fiddle with the config for now (I figure it must be a custom Extension b/c methods like this one look like the hot stuff), and should I feel like I've achieved something presentable there I'll set up a PR. ;) But I'm not sure a can cover all relevant cases where compat it lacking, besides the issues I'm stumbling on in my project.

[B4nan]

Wait, you should be using mariadb driver, that one does not use this query at all.

https://mikro-orm.io/api/mariadb

[JonasDoe]

Thanks for the advice! I figure we need to reconsider what we're actually aiming for. Right now, our approach was to stick with the MySQL 5.7 in all declarations, for the highest likeliness we can switch over to TiDB or Vitess at some point. So even the use of MariaDB was just a sneaky "implementation detail" against the MySQL 5.7 "API". But it seems that this whole approach is falling apart with MySQL 5.7 hitting its EoL, and the issues here are just a symptom for that. 🤔