DBD::MySQL upstream change

pali at cpan.org pali at cpan.org
Sun Mar 31 13:42:01 CEST 2024

On Sunday 31 March 2024 10:03:33 Florian Smeets wrote:
> On 31.03.24 03:34, Noel Butler wrote:
> > On 30/03/2024 22:41, Florian Smeets wrote:
> > 
> > > 
> > > From what I gathered, the DBD:MySQL vs DBD:MariaDB situation is not
> > > easy. You cannot just replace it one for one, some care needs to be
> > > taken.
> > Care to explain this blanket statement? Or are you relating to FreeBSD
> > that does something strange to be that way?
> My mail contained two links which you stripped that explain issues people
> saw when migrating to DBD:MariaDB.
> https://blogs.perl.org/users/grinnz/2023/12/migrating-from-dbdmysql-to-dbdmariadb.html
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277889#c16
> I haven't analyzed it in that much detail to say if it will work in most
> cases or just in a lot of cases, all I'm saying is that some care needs to
> be taken as there are subtle differences, so not a 100% drop-in replacement.
> Florian

Hello, I'm the DBD::MariaDB author and I could explain a few things on
this topic. I must admit that Grinnz on the blog post did excellent
explanation about UNICODE.

DBD::MariaDB forked DBD::mysql few years ago and released its first
version 6 years ago. So it is not a new project. And I know that it is
used in production on lot of places.

At a fork time there were fixed lot of bugs from DBD::mysql bugtracker
which users reported. I think there were 3 big changes which may cause
incompatibility with DBD::mysql.

1) Renaming options. All DBI options which starts with "mysql_*" are
DBD::mysql driver specific and so DBD::MariaDB cannot provide them. It
has to use "mariadb_*" prefix. So if application uses driver specific
mysql_* options they have to be renamed.

2) Fixing TLS support. At a fork time there were security related issues
to TLS, e.g. application asked for TLS encryption and plain text was
uses. DBD::MariaDB does not have these issues, but it may cause problem
for applications which try to enforce TLS and server does not support

3) Fixing UNICODE support. This is the change mentioned in the blog
post. Basically DBD::MariaDB aligns UNICODE support with DBD::SQLite and
DBD::Pg. It changed UNICODE model to the one used by the Perl itself.
So if application is working fine with DBD::SQLite there should be no
issue. DBD::MariaDB removed old DBD::mysql utf8 related connection
options (or rather to say connection workarounds/hacks) which are not
needed anymore and should not be used.

So, you can take it as 1:1 replacement if you have well-behaved DBI
application which does not use any driver-specific things (like those
mysql_* connection attributes), does not depend on DBD::mysql internals
or bugs which were already fixed, and application uses the standard Perl
UNICODE model.

Changes done to DBD::MariaDB after fork can be found in the doc:

Note that DBD::MariaDB still supports also MySQL versions 4.1-8.0.

And there are automated driver tests also for FreeBSD, which passed on
the latest released version. Test suite is same for Linux, Windows and
FreeBSD. Which means that there was no uncovered FreeBSD specific issue.

Anyway, if you need some help with migration, feel free to contact me.


More information about the amavis-users mailing list