Hello Awasum, I will start another thread and also an issue, because my point is that we should standardize the Character Set and the Collation in Fineract before any JDBC Driver Change.
Regards Victor El mar., 28 de septiembre de 2021 2:57 a. m., Awasum Yannick < awa...@apache.org> escribió: > Hi Victor, > > We can't release Fineract 1.x with a mariadb driver as that won't be > compliant with the Apache license. How do we go around that? > > On Tue, Sep 28, 2021 at 6:11 AM VICTOR MANUEL ROMERO RODRIGUEZ < > victor.rom...@fintecheando.mx> wrote: > >> 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 >> >>
