Hello Fineract Community, I have been dealing with this issue for a few weeks. And I would like to receive some ideas about how to proceed. FIY these are the PR and Fineract Issues
https://github.com/apache/fineract/pull/1883 https://issues.apache.org/jira/browse/FINERACT-982 I have received comments about the risk/issue of updating the existing Databases, which I agree is very important to Fineract users once they apply an upgrade or migrate to a newer Fineract version with a new JDBC driver. If we replace the Drizzle driver to MariaDB for example, there are new challenges that are shown, like having different collations in the tables used by Fineract. If we upgrade the JDBC there will be issues running Flyway because the different table collation errors will stop the process of creating/migrating the tables. My opinion is to set an standar for Fineract 1.x about setting the Character Set and the collation. For previous I suggest to use utf8mb4 and utf8mb4_unicode_ci. What do you think? If we agree, then I will focus the effort with the JDBC Driver replacement adding the SQL migration script based on the proposed charset and collation. And also providing advice about the process for migrating the data. I share Francisco Bordenave's thoughts about the migration pain. "... - *First disclosure*: I can’t emphasize enough that you need to always backup your data. If something goes wrong, you can always roll things back by keeping a healthy set of backups. - *Second disclosure*: A backup can’t be considered a good backup until you test it, so I can’t emphasize enough that running regular backups and also performing regular restore tests is a must-to-do task for being in the safe side. - *Third and last disclosure*: I’m not pretending to present the best or only way to do this exercise. This is the way I consider easiest and painless to perform a charset conversion with minimal downtime....." You can read more at https://www.percona.com/blog/2018/04/10/migrating-database-charsets-to-utf8mb4/ Regards Victor
