these changes allow SMUI to run with mysql 8 #145
Conversation
|
Current PR can not be merged to main, as it would harm backwards compatibility of existing SMUI installations. Modifying existing migrations would lead to a major version update, and can not be supported in V4 of SMUI. |
|
Would making the jump then to MySQL 8 be worth bumping the major version to 5 then? MySql 5.6 EOL was in 2021 and 5.7 is October 2023. Quepid was moved to Mysql 8, and the Chorus reference implementation is kind of stuck in between. I did find an interesting way of "patching" a 4.x SMUI to work with MySQL 8: https://github.com/querqy/chorus/pull/163/files#diff-2a301e09731b384355af3f1fe4691b51811ba84654757c2c10c2901858eb54d9 |
|
Would this then rather be a fork of SMUI to properly maintain this one instance that requires these changes? IMO the querqy/smui main should support all clients still depending on it incl. backwards compatability of the data model. I know it's tempting to adjust SQL migrations, but it is tampering backwards compatability. I would rather like to see a direction where changes of the database model happen in line with this requirement. Though we'd probably need to technical spike to properly find out a way forward here (i.e. skipping migrations for certain database clients, switching/migrating to an improved/varied data structure for certain tables). WDYT? |
|
I hadn't really thought about the idea of checking the database client and using that to influence the type of migration made. If that is a viable path forward, then great. It "feels" like a lot of work to support old mysql versus just major version jump and telling folks to manually migrate/reimport their setups, however most important is to come up with a forward motion path and not stagnate. I'm probably waiting for my next SMUI dayjob project to come through before I can push forward on that effort! |
This will fix #130 .