Add MariaDB.pm package

[usna78]

DBD::MySQL does not support MariaDB clients beyond version 4. To use MariaDB versio 10, for exmaple, requires the DBD::MariaDB package. Adding DBIx::Class::SQLmaker::MariaDB allows use of the proper packages.

DBIx::Class::Schema::Loader depends on DBIx::Class::SQLMaker which supports a number of dependent modules such as MySQL.pm, MSSQL.pm, SQLite.pm and Oracle.pm, but did not have a corresponding MariaDB.pm file. So I made a copy of MySQL.pm named MariaDB.pm and then I edited the new MariaDB.pm file to change references to mysql and MySQL to MariaDB.

See: https://blogs.perl.org/users/usna78/2024/05/mariadb-10-and-perl-dbixclassschemaloader.html

[StefanStuehrmann]

Hey @usna78,
as the new MariaDB package only differs in name but not in any of it's functionality I would propose to rather subclass the MySQL package.
This way we would avoid code duplication and we would gain the benefits of changes in the MySQL class also in the MariaDB one.

@ribasushi:
I have an open PR for SQLMaker as well. I read that DBIx::Class is treated as stable and not maintained.
Would it make sense to move the database specific extensions of SQLMaker (SQLMaker) into a separate repository / package so that they can be maintained and extended.

There are new changes in databases that would need to be incorporated and creating additional packages like DBIx::Class:SQLMaker::UpToDateExtensions and dealing with installation via module loading order / version numbering kinda sucks.

The scope for a new maintainer of this part would also be much smaller. What do you think?

[usna78]

The maintainer of DBD::Mysql no longer believes the package needs to support current versions of MariaDB. The package continues to support MariaDB but only if it is version 5 or less. Some insight into this support change is here: perl5-dbi/DBD-mysql#371 (comment). To be fair, it is believed that DBD::MariaDB is a fully capable package.

The stub approach will call Mysql.pm instead of MariaDB.pm. This means DBD::mysql is a dependency. But trying to load DBD::mysql intentionally fails if your client is a newer Mariadb (such as 10 or 11). So the stub approach creates the need for a work-around just to get DBD::mysql to build.

Therefore, even though the duplication is regrettable, I favor a separate Maria.pm package -- because of clean dependencies on DBD::MariaDB and the need to avoid tricking the DBD::mysql into installing when it is being designed not to.

[usna78]

I have limited knowledge of all things DBIx::Class except as an end user. So I will trust the current maintainers to do with my patch input what they think is best. It appears to me that MariaDB continues to gain popularity and also continues to diverge from mysql. The MariDB site lists the differences here: https://mariadb.com/kb/en/incompatibilities-and-feature-differences-between-mariadb-11-4-and-mysql-8-/ My code submission is currently duplicative of the Mysql code already in place.. But setting up MariaDB.pm as standalone code in the many packages under DBIx::Class that lack it will be increasingly beneficial as mysql and MariaDB continue to diverge. This approach also allows persons offering fixes to not have to test them against both MariaDB and MySQL. For example, an end user with MariaDB installed cannot be reasonably expected to install MySQL on a system just to see if the same bug exists and if the same fix corrects it. Of course that would be great -- but it is not expected. The maintainers of the mysql.pm and Maria.pm code can review their respective issues/pull requests and apply similar patches if similarities exist. Let me know how I can help move things forward. Russ Brewer ***@***.***

…

On Tue, Jun 3, 2025 at 10:12 AM Stefan Stührmann ***@***.***> wrote: *StefanStuehrmann* left a comment (Perl5/DBIx-Class#151) <#151 (comment)> Hey @usna78 <https://github.com/usna78>, as the new MariaDB package only differs in name but not in any of it's functionality I would propose to rather subclass the MySQL package. This way we would avoid code duplication and we would gain the benefits of changes in the MySQL class also in the MariaDB one. @ribasushi <https://github.com/ribasushi>: I have an open PR for SQLMaker as well. I read that DBIx::Class is treated as stable and not maintained. Would it make sense to move the database specific extensions of SQLMaker (SQLMaker) into a separate repository / package so that they can be maintained and extended. There are new changes in databases that would need to be incorporated and creating additional packages like DBIx::Class:SQLMaker::UpToDateExtensions and dealing with installation via module loading order / version numbering kinda sucks. The scope for a new maintainer of this part would also be much smaller. What do you think? — Reply to this email directly, view it on GitHub <#151 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMNRHKPP7CT5LHJWACUNVD3BWUOBAVCNFSM6AAAAAB6NYXKTSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMZVGQ3TANZSGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[melutovich]

@ribasushi We also are now using DBD::MariaDB so some solution (this PR or another) for this would be appreciated.