-
Notifications
You must be signed in to change notification settings - Fork 152
Add MariaDB.pm package #151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: maint/0.0828xx
Are you sure you want to change the base?
Conversation
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
Hey @usna78, @ribasushi: 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? |
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. |
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:
***@***.***>
|
@ribasushi We also are now using DBD::MariaDB so some solution (this PR or another) for this would be appreciated. |
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