I am looking forward to migrate environments including a database upgrade from MariaDB 10.11 to 11.8.
I wonder, what will be the impact on Jmix applications using MariaDB persistence?
Especially since migrating from Jmix 2.4 to 2.5, I had to pin to an old liquibase version.
https://docs.jmix.io/jmix/2.4/whats-new/index.html#changelog-generation-for-mariadb
What will be the future of MariaDB support in Jmix applications?
Hello!
All actual versions of MariadDB (including 10.x and 11.x) are fully supported in Jmix, and there are no plans to change that.
As for Liquibase version: unfortunately, they changed the UUID column generation db type from char(36) to uuid in one of updates after 4.25.0 (in 4.25.1 if I remember correctly).
This unexpected change is not compatible with existing databases: foreign keys don’t work between char(36) (existing tables) and uuid (newly created tables) columns. No feature toggle or easy way to restore the old behaviour has been provided. It appears that only older versions of Liquibase are compatible with existing databases without additional migration or Liquibase logic extension.
Given that, to avoid breaking support for existing projects, an older version have to be pinned.
Currently, it is the recommended approach, also considering that not all current versions of MariaDB support uuid columns. We’ll add a version constraint to the framework in a future release, in order to not manage it in project’s build.gradle.
Regards,
Dmitry
@taimanov Thank you, for explaining more details.
So for existing Jmix applications which already have generated table structures using char(36)-type based uuids will keep running after upgrading MariaDB from 10.11 to 11.8 with the old pinned liquibase version.
char(36)-type based to uuid-type-based tables is a future topic.Creating new Jmix applications with MariaDB 11 using uuid-type based identifiers is not supported (or not recommended) yet, correct?
So for existing Jmix applications which already have generated table structures using
char(36)-type based uuids will keep running after upgrading MariaDB from10.11to11.8with the old pinned liquibase version.
Yes. No problems were noticed.
Creating new Jmix applications with MariaDB 11 using
uuid-type based identifiers is not supported (or not recommended) yet, correct?
Correct. For now, uuid IDs are converted to string without dashes (e.g. 608859871b61424794c7dff348347f93) for MariaDB/MySQL. The uuid column type does not accept such format.
We are working on adding support for uuid columns mode for MariaDB and on providing the ability to enable it manually.
Hi all and @taimanov
All actual versions of MariadDB (including 10.x and 11.x) are fully supported in Jmix, and there are no plans to change that.
This idea is nice, but in reality not true !
Just create an empty project with Jmix 2.6.1 with MariaDB and it is not even possible to login !!
And all this only, because of one simple conversion in String32UuidConverter.java#convertDataValueToObjectValue.
There is a check, if the input object is a string and in this case, there are - inserted in the string. I think a simple check, if these - are already there (and in this case not adding them again), and the problem is solved.
I really don’t know why this simple Problem is not been solved for a long time already. I think a lot of developers after creating a new project with MariaDB and facing this problem will just give up. For me; MariaDB is actually not supported.
My opinion which I did express several times already, but seems just ignored.
Regards
Felix
I share your frustrations regarding the MariaDB issue. I’ve been having problems since the release of 2.4, almost a year ago.
I appreciated the timely gradle fix that was offered last November, and the fact that it was added to the documentation. However, I thought it was a short-term solution. I was a bit apprehensive to read in this thread that a “version constraint” would be added to a future Jmix release. Does this mean that MariaDB users would continue to be held back at Liquibase 4.25? How long would that be a viable solution?
Perhaps I misunderstood what was posted in #4709 a couple of weeks ago. Based on my cursory reading, I anticipated that uuid would be replaced by varchar for MariaDB. When I saw that #3888 had been moved from “in progress” to “review” status, I was expecting to be able to test this in the upcoming Jmix 2.7 release candidate.
Assuming replacing uuid with varchar is a good solution, I can envision that it would only work for new projects and that existing projects may require manual fixes. Maybe that’s too ambitious for the 2.7 release. I’d love to see more discussion here about what we can expect.
My thanks to anyone who can provide additional clarification on this issue.
Doug
Hello all!
Just create an empty project with Jmix 2.6.1 with MariaDB and it is not even possible to login !!
As mentioned in the documentation, using MariaDB currently requires downgrading the Liquibase version. I understand and agree that this is inconvenient. The requirement to add this line to build.gradle will be removed in the next release.
There is a check, if the input object is a string and in this case, there are - inserted in the string. I think a simple check, if these - are already there (and in this case not adding them again), and the problem is solved.
@f.zehnder, unfortunately, this simple check is not enough to solve the whole issue. Yes, it will prevent the exception you mentioned and allow the value to be read from db. But then a new problem occurs: saving UUID values to the DB.
We cannot use the new format (with dashes). In that case we either won’t be able to save an entity with foreign keys (because the ID format of the referenced entity has not been updated yet), or we will have to force every MariaDB project to perform a full db migration of PK and FK columns.
We also cannot use the old format (without dashes). UUID colums newly created by liquibase 4.25.1+ will not accept values in the old format.
Moreover, this is not only Jmix conversion problem. Imagine that there is no Jmix – just a simple app with MariaDB (e.g. 11.8.3) and Liquibase:
ERROR: Exception Primary Source: MariaDB 11.8.3-MariaDB-ubu2404
Unexpected error running Liquibase: liquibase.exception.MigrationFailedException: Migration failed for changeset com/company/mariatst2/liquibase/changelog/2025/09/29-181318-8ce57fb5.xml::2::mariatst2:
Reason: liquibase.exception.DatabaseException: (conn=392) Can't create table `mariatst2`.`TEST2` (errno: 150 "Foreign key constraint is incorrectly formed") [Failed SQL: (1005) ALTER TABLE mariatst2.TEST2 ADD CONSTRAINT FK_TEST2_ON_TEST1 FOREIGN KEY (TEST1_ID) REFERENCES mariatst2.TEST (ID)]
For more information, please use the --logLevel flag
Exception in thread "main" liquibase.exception.LiquibaseException: Unexpected error running Liquibase: liquibase.exception.MigrationFailedException: Migration failed for changeset com/company/mariatst2/liquibase/changelog/2025/09/29-181318-8ce57fb5.xml::2::mariatst2:
Reason: liquibase.exception.DatabaseException: (conn=392) Can't create table `mariatst2`.`TEST2` (errno: 150 "Foreign key constraint is incorrectly formed") [Failed SQL: (1005) ALTER TABLE mariatst2.TEST2 ADD CONSTRAINT FK_TEST2_ON_TEST1 FOREIGN KEY (TEST1_ID) REFERENCES mariatst2.TEST (ID)]
at liquibase.integration.commandline.Main$1.run(Main.java:442)
at liquibase.integration.commandline.Main$1.run(Main.java:225)
at liquibase.Scope.child(Scope.java:210)
at liquibase.Scope.child(Scope.java:186)
at liquibase.integration.commandline.Main.run(Main.java:225)
at liquibase.integration.commandline.Main.main(Main.java:164)
It happens because an FK cannot be created between UUID and CHAR(36) columns. Liquibase also does not provide an easy solution to generate CHAR(36) columns on already existing databases.
So, the problem is not a simple check. The real issue is that upgrading Liquibase makes further development on existing DBs impossible without either:
CHAR(36) ID columns to UUID type, oruuid type with char(36) and then dealing with checksum changes (if Liquibase uuid is replaced by varchar, as @dmitchell suggested).As for new projects, we may face similar issues using a newer Liquibase version with MariaDB 10.6 ( which is still in use and does not support the UUID column type). For MariaDB 10.6 Liquibase still creates CHAR(36) columns. So, if someone creates a new project on a newer Liquibase version with MariaDB 10.6 and then tries to migrate to MariaDB 10.7+, they will encounter the same Foreign key constraint is incorrectly formed exception for newly added entities.
Thus, at the moment, the only reliable way to support all MariaDB versions without forcing very inconvenient migrations is to pin the Liquibase version.
We are considering possible solutions for one of the future releases when Liquibase version will be updated and will provide additional information once we implement one of them.
Regards,
Dmitry
Hi @taimanov
Thanks a lot for your investigations and explanations.
How about the idea MariaDB <= 10.6 has to stick to liquibase 4.25 and the newer MariaDB is working with UUID. People who do not like to stick to liquibase 4.25 and use a newer version of MariaDB have to migrate ? Or vice versa, who does not want/can migrate, has to stick to 4.25.
I think, one of the most important points actually, is that out of the box Jmix is supporting new projects with MariaDB 10.7+ and in this situation running smoothly. And this has to be mentioned !
If somebody is trying a new product and gets the speech, MariaDB is fully supported and facing this error, just drops Jmix. And I don’t want that, agree ?
Nevertheless, any nicer solution is appreciated, but I see the problem now clearer. Another idea is just to drop liquibase, as his reputation here on the forum is not the best …
Best regards
Felix