perl5-dbi / dbd-mariadb Goto Github PK
View Code? Open in Web Editor NEWPerl MariaDB driver
License: Other
Perl MariaDB driver
License: Other
I'd like to use this driver as a drop-in replacement for DBD::mysql (the same way MariaDB is a drop-in replacement for MySQL) so that existing code doesn't have to be rewritten to use the new function names. Aside from reverting all the commits where the function names were changed is there any way to do this?
Compile time macro MYSQL_VERSION_ID
should be replaced by runtime function mysql_get_client_version()
where possible. This allows to update system MariaDB/MySQL client library without need to recompile DBD::MariaDB XS module. Reason: Lot of Linux distributions compile DBD::MariaDB just once and not with every minor MariaDB/MySQL client library update.
Since 50da6b0 (released in 1.10) non-embedded version of DBD::MariaDB
calls mysql_server_end
.
mysql_server_end
by default de-initialize OpenSSL (in vio_end
function), this unfortunately confuse other libraries using OpenSSL (like SSleay
used for HTTPS), which does not expect it.
Problem is known in MySQL under https://jira.mariadb.org/browse/MDEV-6671.
Please set mariadb_deinitialize_ssl
to 0
(or make it configurable), so OpenSSL is not de-initialized.
Reproducer (using OpenSSL 1.0.2k):
use warnings;
use strict;
use LWP::UserAgent;
use DBI;
use IO::Socket::SSL;
my $ua;
my $res;
my $m;
$ua = LWP::UserAgent->new();
$res = $ua->get("https://www.google.com");
$m = DBI->connect('DBI:MariaDB:database=test;host=localhost', 'user', 'password');
$m = undef;
$res = $ua->get("https://www.google.com");
print($res->content);
print($IO::Socket::SSL::SSL_ERROR);
$ perl m.pl
Can't connect to www.google.com:443
SSL Context init failed error:140A90F1:lib(20):func(169):reason(241)
The links on the README page to DBD::MariaDB are broken, and cpan is not aware of any module named DBD::MariaDB.
It is not documented, but DBD::mysql supports the user/pass in the DSN, which is very handy in dynamic DSN's and testing.
Would you consider allowing user/pass in DSN?
$dsn = "dbi:MariaDB:dbname=foo;user=tux;pass=secrit";
$dsn = "dbi:MariaDB:database=foo;username=tux;password=secrit";
I am testing the JSON data type in a MariaDB database. Here is the table create statement
CREATE TABLE `vs` (
`AutoID` INT(10) UNSIGNED ZEROFILL NOT NULL AUTO_INCREMENT,
`ShowID` VARCHAR(25) NULL DEFAULT '0' COLLATE 'utf8mb4_unicode_ci',
`ClientID` VARCHAR(25) NULL DEFAULT '0' COLLATE 'utf8mb4_unicode_ci',
`Categories` LONGTEXT NULL DEFAULT '0' COLLATE 'utf8mb4_bin',
`Attr` LONGTEXT NULL DEFAULT '0' COLLATE 'utf8mb4_bin',
`UUID` VARCHAR(50) NULL DEFAULT '0' COLLATE 'utf8mb4_unicode_ci',
PRIMARY KEY (`AutoID`),
UNIQUE INDEX `VSUUID` (`UUID`),
INDEX `VS-Show` (`AutoID`, `ShowID`, `ClientID`),
INDEX `VS-clientID` (`ClientID`)
)
COLLATE='utf8mb4_unicode_ci'
ENGINE=InnoDB
;
Here is the sample row data
INSERT INTO `vs` (`AutoID`, `ShowID`, `ClientID`, `Categories`, `Attr`, `UUID`) VALUES (0000000001, 'Demo', 'NEA', '{"buttonfmt": "red", "categories": ["Parts", "Paint / PBE / Refinishing", "OEM / Auto Manufacturer", "Tools & Equipment", "Education / Trade Organization / Consulting", "Mechanical Repair", "Other"]}', '0', 'c41ac5cb-d900-4991-9c3e-0b710fded735');
When I execute the following perl code I do not see any data for the result column
use strict;
use DBI;
use Data::Dumper;
our $SQL;
our $sth='';
my $UUID;
my $rv;
my $dbh = DBI->connect("DBI:MariaDB:IBKREG:localhost",
'UserID', 'Password',
{ RaiseError => 1, PrintError => 0 });
$SQL="select Showid, JSON_EXTRACT(categories,'$.buttonfmt') as result from ibkreg.vs where ClientID='NEA';";
$sth = $dbh->prepare($SQL);
$sth->execute();
while (my $hr = $sth->fetchrow_hashref) {
print Dumper($hr);
}
exit;
The following is the output from Data::Dumper
$VAR1 = {
'Showid' => 'Demo',
'result' => undef
};
When I run the SQL statement in Heidi SQL I get "RED" in the Result field as I should. I have updated DBI and the DBD::mysql and DBD::MariaDB modules. Am I missing something?
I have tested this in Python3 and I get the data i expect.
F:\perl\git\DBD-MariaDB-1.00\DBD-MariaDB-1.00>gmake
"F:\perl\Strawberry\perl\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty -- MariaDB.bs blib\arch\auto\DBD\MariaDB\MariaDB.bs 644
gcc -c -IF:\perl\Strawberry\perl\vendor\lib\auto\DBI -IF:\perl\STRAWB~1\c\bin\..\include\mysql50716 -DHAVE_DBI_1_634 -DHAVE_GET_OPTION -s -O2 -DWIN32
-DWIN64 -DCONSERVATIVE -D__USE_MINGW_ANSI_STDIO -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv -fno-strict-
aliasing -mms-bitfields -s -O2 -DVERSION=\"1.00\" -DXS_VERSION=\"1.00\" "-IF:\perl\STRAWB~1\perl\lib\CORE" dbdimp.c
In file included from F:\perl\Strawberry\perl\vendor\lib\auto\DBI/DBIXS.h:38:0,
from dbdimp.h:20,
from dbdimp.c:16:
F:\perl\Strawberry\perl\vendor\lib\auto\DBI/dbipport.h:4471:0: warning: "WIDEST_UTYPE" redefined
# define WIDEST_UTYPE U64TYPE
In file included from F:\perl\STRAWB~1\perl\lib\CORE/perl.h:2465:0,
from F:\perl\Strawberry\perl\vendor\lib\auto\DBI/DBIXS.h:23,
from dbdimp.h:20,
from dbdimp.c:16:
F:\perl\STRAWB~1\perl\lib\CORE/handy.h:1064:0: note: this is the location of the previous definition
# define WIDEST_UTYPE U64
In file included from F:\perl\Strawberry\perl\vendor\lib\auto\DBI/DBIXS.h:23:0,
from dbdimp.h:20,
from dbdimp.c:16:
dbdimp.c: In function 'free_embedded_options':
F:\perl\STRAWB~1\perl\lib\CORE/perl.h:175:16: error: 'my_perl' undeclared (first use in this function); did you mean 'my_bool'?
# define aTHX my_perl
^
F:\perl\STRAWB~1\perl\lib\CORE/embedvar.h:38:18: note: in expansion of macro 'aTHX'
# define vTHX aTHX
^~~~
F:\perl\STRAWB~1\perl\lib\CORE/embedvar.h:55:19: note: in expansion of macro 'vTHX'
#define PL_Mem (vTHX->IMem)
^~~~
F:\perl\STRAWB~1\perl\lib\CORE/iperlsys.h:816:4: note: in expansion of macro 'PL_Mem'
(*PL_Mem->pFree)(PL_Mem, (buf))
^~~~~~
F:\perl\STRAWB~1\perl\lib\CORE/XSUB.h:613:19: note: in expansion of macro 'PerlMem_free'
# define free PerlMem_free
^~~~~~~~~~~~
dbdimp.c:548:7: note: in expansion of macro 'free'
free(options_list[i]);
^
F:\perl\STRAWB~1\perl\lib\CORE/perl.h:175:16: note: each undeclared identifier is reported only once for each function it appears in
# define aTHX my_perl
^
F:\perl\STRAWB~1\perl\lib\CORE/embedvar.h:38:18: note: in expansion of macro 'aTHX'
# define vTHX aTHX
^~~~
F:\perl\STRAWB~1\perl\lib\CORE/embedvar.h:55:19: note: in expansion of macro 'vTHX'
#define PL_Mem (vTHX->IMem)
^~~~
F:\perl\STRAWB~1\perl\lib\CORE/iperlsys.h:816:4: note: in expansion of macro 'PL_Mem'
(*PL_Mem->pFree)(PL_Mem, (buf))
^~~~~~
F:\perl\STRAWB~1\perl\lib\CORE/XSUB.h:613:19: note: in expansion of macro 'PerlMem_free'
# define free PerlMem_free
^~~~~~~~~~~~
dbdimp.c:548:7: note: in expansion of macro 'free'
free(options_list[i]);
^
gmake: *** [Makefile:349: dbdimp.o] Error 1
F:\perl\git\DBD-MariaDB-1.00\DBD-MariaDB-1.00>perl -v
This is perl 5, version 28, subversion 0 (v5.28.0) built for MSWin32-x64-multi-thread
strawberry-perl-5.28.0.1-64bit.msi
As I have read Unicode explanation multiple times and code works with old MySQL driver (which Unicode support is considered borked there I just enable utf8 support and everything works). With MariaDB example char 'ö' converts for chars: ö. This same issue can be achieved with Perl JSON-module when you enable UTF8 mode and they already are UTF8 so they are blindly converted second time.
Main problem is that when one haves string like with UTF-8 char 'ö' it still converts them to Unicode second time (ö).
It was observed that DBD::MariaDB 1.23 seems not updating cardinality in MariadB 10.6.5. Once we replace 1.23 binaries with 1.21, everything seems started working.
There seem to be some utf8mb4 encoding problems with the DBD-MariaDB driver. I confirmed that the data is scrambled in the database so this isn't a display problem.
The DB schema column is created with:
subject varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT '',
Switching over to the perl-DBD-MySQL driver fixes the issue. This is a Centos 8 server with perl 5, version 26, subversion 3 (v5.26.3)
Hello,
just a little error:
--- a/lib/DBD/MariaDB.pod
+++ b/lib/DBD/MariaDB.pod
@@ -1041,7 +1041,7 @@
Moreover, DBI API for L<do|DBI/do>, L<execute|DBI/execute> and all
L<select*|DBI/selectrow_array> methods binds all parameters as C<SQL_VARCHAR>
-type. Currently it is an API limitation which does not allow to specify the bind
+type. Currently it is an API limitation which does not allow one to specify the bind
type. Varchar is a string and so DBD::MariaDB treats all of them as I<Unicode>
strings.
Hello, why you break a compatibility with DBD::mysql
i mean mysql_insertid => mariadb_insertid and else mysql_* to mariadb_*
because i need refactor whole app to use you driver
Using DBD::MariaDB 1.00 and mariadb 10.0.36-MariaDB-0ubuntu0.16.04.1 on ubuntu 16.04, I am seeing differences in the TYPE attribute of a statement handle than DBD::mysql 4.033 reported. This is my test table:
CREATE TABLE `bar` (
`bigint` bigint(20) DEFAULT NULL,
`bit` bit(6) DEFAULT NULL,
`decimal` decimal(10,0) DEFAULT NULL,
`double` double DEFAULT NULL,
`float` float DEFAULT NULL,
`int` int(11) DEFAULT NULL,
`smallint` smallint(6) DEFAULT NULL,
`tinyint` tinyint(4) DEFAULT NULL,
`date` date DEFAULT NULL,
`time` time DEFAULT NULL,
`datetime` datetime DEFAULT NULL,
`timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`mediumint` mediumint(9) DEFAULT NULL,
`year` year(4) DEFAULT NULL,
`char` char(1) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
`varchar` varchar(1) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
`binary` binary(1) DEFAULT NULL,
`varbinary` varbinary(1) DEFAULT NULL,
`enum` enum('1') COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
`set` set('1') COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
`tinyblob` tinyblob,
`tinytext` tinytext COLLATE utf8mb4_unicode_520_ci,
`blob` blob,
`text` text COLLATE utf8mb4_unicode_520_ci,
`mediumblob` mediumblob,
`mediumtext` mediumtext COLLATE utf8mb4_unicode_520_ci,
`longblob` longblob,
`longtext` longtext COLLATE utf8mb4_unicode_520_ci
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci
and these are the TYPE values returned for the mariadb and mysql clients:
{
"bigint" : {
"maria" : 18446744073709551611,
"mysql" : -5
},
"binary" : {
"maria" : 1,
"mysql" : 1
},
"bit" : {
"maria" : 18446744073709551609,
"mysql" : 12
},
"blob" : {
"maria" : 18446744073709551612,
"mysql" : -4
},
"char" : {
"maria" : 1,
"mysql" : 1
},
"date" : {
"maria" : 9,
"mysql" : 9
},
"datetime" : {
"maria" : 11,
"mysql" : 11
},
"decimal" : {
"maria" : 3,
"mysql" : 3
},
"double" : {
"maria" : 8,
"mysql" : 8
},
"enum" : {
"maria" : 1,
"mysql" : 1
},
"float" : {
"maria" : 6,
"mysql" : 7
},
"int" : {
"maria" : 4,
"mysql" : 4
},
"longblob" : {
"maria" : 18446744073709551612,
"mysql" : -4
},
"longtext" : {
"maria" : 18446744073709551612,
"mysql" : -4
},
"mediumblob" : {
"maria" : 18446744073709551612,
"mysql" : -4
},
"mediumint" : {
"maria" : 4,
"mysql" : 4
},
"mediumtext" : {
"maria" : 18446744073709551612,
"mysql" : -4
},
"set" : {
"maria" : 1,
"mysql" : 1
},
"smallint" : {
"maria" : 5,
"mysql" : 5
},
"text" : {
"maria" : 18446744073709551612,
"mysql" : -4
},
"time" : {
"maria" : 10,
"mysql" : 10
},
"timestamp" : {
"maria" : 11,
"mysql" : 11
},
"tinyblob" : {
"maria" : 18446744073709551612,
"mysql" : -4
},
"tinyint" : {
"maria" : 18446744073709551610,
"mysql" : -6
},
"tinytext" : {
"maria" : 18446744073709551612,
"mysql" : -4
},
"varbinary" : {
"maria" : 12,
"mysql" : 12
},
"varchar" : {
"maria" : 12,
"mysql" : 12
},
"year" : {
"maria" : 5,
"mysql" : 5
}
}
mariadb_st_finish() calls mariadb_db_async_result() without checking return value. mariadb_db_async_result() can fail and it that case mariadb_st_finish() should also signal an error.
It started to fail in openSUSE Tumbleweed about two weeks ago, maybe an issue with a dependency that changed its output?
[ 6s] [156/170] cumulate libmariadb3-3.3.10-1.1
[ 6s] [159/170] cumulate mariadb-client-11.4.2-1.1
[ 6s] [168/170] cumulate mariadb-11.4.2-1.1
[ 6s] [170/170] cumulate libmariadb-devel-3.3.10-1.1
...
[ 18s] 2024-07-04 22:24:19 120 [Warning] Aborted connection 120 to db: 'unconnected' user: 'unauthenticated' host: 'localhost' (This connection closed normally without authentication)
[ 18s]
[ 18s] # Failed test 'DBD::MariaDB supports mariadb_ssl=1 without mariadb_ssl_optional=1 and fail because cannot enforce SSL encryption'
[ 18s] # at t/92ssl_connection.t line 32.
[ 18s] # 'TLS/SSL error: self-signed certificate'
[ 18s] # doesn't match '(?^:^SSL connection error: )'
[ 18s] # Error message: TLS/SSL error: self-signed certificate
[ 18s] # Looks like you failed 1 test of 2.
[ 18s] t/92ssl_connection.t ....................
[ 18s] Dubious, test returned 1 (wstat 256, 0x100)
[ 18s] Failed 1/2 subtests
Although there are some tests for DBD-MariaDB at the Test Matrix, it seems Maria-DB is not available on CPAN.
That would not only make the distribution easily available for developer, but it would also take advantage of the several smoker testers available around the world.
I don't have a new enough MySQL handy, but in a bug report for Mojo::mysql it was indicated with a test case that when selecting from a JSON type column, the output is not UTF-8 decoded (jhthorsen/mojo-mysql#57 (comment)). MySQL documents that when JSON is interacted with as a string it is treated as the utf8mb4 charset so it should be returned that way, the same way it is passed as a utf8mb4 string.
The issue should be reproducible by inserting into a JSON type column with a query like so:
INSERT INTO unicode_json_test SET my_json = JSON_OBJECT('drink', CONVERT(UNHEX('537AC5916CC5916CC3A9') USING utf8mb4));
then selecting that column. JSON and encoding is a tricky subject because it is commonly represented as UTF-8 encoded bytes rather than text, but as MySQL treats it on input and output as a character string, it should be decoded as the input string is encoded; this also is what happens in DBD::Pg.
Also opened for DBD::mysql perl5-dbi/DBD-mysql#309
Similar to perl5-dbi/DBD-mysql#388 DBD-MariaDB needs to check whether a database handle is active (has not been disconnected) before attempting to prepare or execute queries against that handle
ERROR MESSAGE:
Can't find 'boot_DBD__MariaDB' symbol in M:/MariaDB/lib/libMariaDB.dll
Distribution: DBD::MariaDB (repo MetaCPAN)
Module version: 1.21
COMPLETE PERL SCRIPT TO DEMONSTRATE ERROR:
#!/usr/bin/perl
use DBD::MariaDB;
ENVIRONMENT
Windows 10 Pro (64))
Version: 20H2
Build: 19042.1415
"perl -v" returns:
Perl 5, version 32, subversion 1 (v5.32.1) built for MSWin32-x64-multi-thread
Visual Studio 2008
StrawberryPerl
strawberry-perl-5.32.1.1-64bit installed from msii
MariaDB:
innodb_version | 10.6.5 |
| protocol_version | 10 |
| slave_type_conversions | |
| system_versioning_alter_history | ERROR |
| system_versioning_asof | DEFAULT |
| tls_version | TLSv1.1,TLSv1.2,TLSv1.3 |
| version | 10.6.5-MariaDB |
| version_comment | mariadb.org binary distribution |
| version_compile_machine | x64 |
| version_compile_os | Win64 |
| version_malloc_library | system |
| version_source_revision | 109fc67d4da46d52d2a96528eaea3b0ef6275692 |
| version_ssl_library | WolfSSL 4.8.1 |
my.ini:
[mysqld]
datadir=M:/MariaDB/data
port=3306
innodb_buffer_pool_size=2038M
[client]
port=3306
plugin-dir=M:/MariaDB/lib/plugin
SELECT @@log_error returns M:\MariaDB\data\Lab02.err which is empty.
The case for value "MYSQL_TYPE_NULL" (dbdimp.c:4779) is not terminated by a "break" statement.
It check a buffer type and it does not make sense to fall through to another case.
Currently it is not possible to enable MariaDB 10.5+ and MySQL 8.1+ server versions in Github Actions CI because Perl module MySQL::Sandbox reject these new versions during installation phase.
We have the following bug reported to the Debian package of
DBD-MariaDB (https://bugs.debian.org/919071):
It doesn't seem to be a bug in the packaging, so you may want to take
a look. Thanks!
------8<-----------8<-----------8<-----------8<-----------8<-----
Source: libdbd-mariadb-perl
Version: 1.11-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
As noticed by Otto in #917303, the MariaDB update from 10.3.11 to
10.3.12 causes a test failure in libdbd-mariadb-perl:
t/55utf8.t ..............................
1..84
ok 1
ok 2
ok 3 - testing quoting of utf 8 string
ok 4 - testing quoting of blob
ok 5 - SET SQL_MODE=''
ok 6
ok 7
ok 8
ok 9
ok 10
ok 11
ok 12
ok 13
ok 14
ok 15 - got warning for INSERT
not ok 16 - warning is correct
ok 17
ok 18 - got data
ok 19
ok 20
ok 21
ok 22
ok 23
ok 24
ok 25
ok 26 - compare �<80>dam eq �<80>dam
ok 27
ok 28 - SET character_set_results='latin1'
ok 29 - got data
ok 30 - utf8 data are returned as latin1 when @@character_set_results is latin1
ok 31 - blob is unchanged when @@character_set_results is latin1
ok 32 - utf8 data are returned as latin1 when @@character_set_results is latin1
ok 33 - utf8 data are returned as latin1 when @@character_set_results is latin1
ok 34 - utf8 data are returned as latin1 when @@character_set_results is latin1
ok 35 - latin1 data are returned as latin1 when @@character_set_results is latin1
ok 36 - latin1 data are returned as latin1 when @@character_set_results is latin1
ok 37
ok 38
ok 39 -
ok 40 - SET character_set_results='utf8mb4'
ok 41
ok 42
ok 43
ok 44
ok 45 - testing quoting of utf 8 string
ok 46 - testing quoting of blob
ok 47 - SET SQL_MODE=''
ok 48
ok 49
ok 50
ok 51
ok 52
ok 53
ok 54
ok 55
ok 56
ok 57 - got warning for INSERT
not ok 58 - warning is correct
ok 59
ok 60 - got data
ok 61
ok 62
ok 63
ok 64
ok 65
ok 66
ok 67
ok 68 - compare �<80>dam eq �<80>dam
ok 69
ok 70 - SET character_set_results='latin1'
ok 71 - got data
ok 72 - utf8 data are returned as latin1 when @@character_set_results is latin1
ok 73 - blob is unchanged when @@character_set_results is latin1
ok 74 - utf8 data are returned as latin1 when @@character_set_results is latin1
ok 75 - utf8 data are returned as latin1 when @@character_set_results is latin1
ok 76 - utf8 data are returned as latin1 when @@character_set_results is latin1
ok 77 - latin1 data are returned as latin1 when @@character_set_results is latin1
ok 78 - latin1 data are returned as latin1 when @@character_set_results is latin1
ok 79
ok 80
ok 81 -
ok 82 - SET character_set_results='utf8mb4'
ok 83
ok 84
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/84 subtests
[�]
Test Summary Report
- -------------------
t/55utf8.t (Wstat: 512 Tests: 84 Failed: 2)
Failed tests: 16, 58
Non-zero exit status: 2
Files=89, Tests=3262, 39 wallclock secs ( 0.64 usr 0.13 sys + 8.42 cusr 1.11 csys = 10.30 CPU)
Result: FAIL
Failed 1/89 test programs. 2/3262 subtests failed.
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlw56IJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZ8BxAAjTMWleXBRtmNVdeTo4L3qbr86thuRKMT0wauDoUY1fMPYgRSfziwLN7b
+7+8/MCb9ESOTGkacZulH3bPmRELV/LkDJN3XbAL1KcrQT0eMb2s4q2VXLybgoE8
q8pupqfwaEI2G7DGCOBralbMYtZ3UWyy2bJsQIBY+JcZk95yl1ulHoI+n1m//ETs
UpKlHrQPB01wGqDm+K95Cpxv5Zvym3a9n1Bzw2WCNIFf9NX85R+lKlKn7my+J9+j
Bllr80/BCcCUmjG/fIMxI2SiEmOgeTJwoLpQ14cpN1BlS3nWW+AXCHDX+G1MHGDS
9Lc4sh0b58MyBBfLnPvW+SUHhDX3R1ZZmKh3JLPH2tSKTeWDsEBBNih7D1hkB2hV
xiqqlQ0Y2SpUSVhvRUsKJ7Hdoqx4ko5X/9xG/kXC2ke6EYnKJzJ5JKwvogZ3AnDz
PSMh8EpcZTGZkD5Q1AiwHQaow/nmNEJJQXyov4qGeiwpX7ERt/7wWIbCCfHp9Zjp
jG8LEpgJu9A2iTxbevpFUEVVLw8i2dzmYnLW1XcpUdTTpJ7yqn5JYXGDzuNpvUyO
69X0A4o5m+3kObFdwQqgVfIMignbyQFRvDb5/eCuVz7zCiZsIl9bRt2YgsH3l4Kv
XcXnL7a5H3DUo3BsaHsPIvqkKXtn3Cn2zMpm7HRpbqA6ecm7VDI=
=L0uA
-----END PGP SIGNATURE-----
------8<-----------8<-----------8<-----------8<-----------8<-----
Thanks for considering,
gregor herrmann,
Debian Perl Group
Since Ubuntu rolled out libmysqlclient21 8.0.34-0ubuntu0.22.04.1
, a warning is thown everytime DBD::MariaDB connects: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.
This is due to the deprecation of MYSQL_OPT_RECONNECT
, which is only used at:
Lines 2364 to 2371 in e81937d
Copied from there:
The MySQL client library currently supports performing an automatic reconnection to the server if it finds that the connection is down and an application attempts to send a statement to the server to be executed. Now, this feature is deprecated and subject to removal in a future release of MySQL.
The related MYSQL_OPT_RECONNECT option is still available but it is also deprecated. C API functions mysql_get_option() and mysql_options() now write a deprecation warning to the standard error output when an application specifies MYSQL_OPT_RECONNECT. (WL #15766)
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-34.html#mysqld-8-0-34-deprecation-removal
https://dev.mysql.com/doc/relnotes/mysql/8.1/en/news-8-1-0.html#mysqld-8-1-0-deprecation-removal
README.pod is included in the root of the distribution. This is discouraged (and a warning is produced under newer EUMM) because EUMM will install any .pm and .pod files from the root -- this one will end up at DBD/README.pod which is an unhelpful location and a namespace not owned by this distribution. It should be excluded from the distribution, only plaintext or .md READMEs should be shipped in the root.
Using the code from Github at 7eba1f3
Perl 5.28.0 (https://hub.docker.com/_/perl)
MySQL libraries from repo.mysql.com
MariaDB 10.3 on host 'maria3'
Test script (disconnect.t):
#!/usr/bin/env perl
use strict;
use warnings;
use DBI;
use Test::More tests => 3;
note 'One';
ok my $dbh = DBI->connect(split /--/, $ENV{TEST_DB});
note 'Two';
ok $dbh->disconnect;
note 'Three';
ok $dbh = DBI->connect(split /--/, $ENV{TEST_DB});
Try with DBD::MariaDB.
# export TEST_DB=DBI:MariaDB:database=test:host=maria3--testuser--mysecretpassword
# prove -v disconnect.t
disconnect.t ..
1..3
# One
ok 1
# Two
ok 2
# Three
Failed 1/3 subtests
Test Summary Report
-------------------
disconnect.t (Wstat: 11 Tests: 2 Failed: 0)
Non-zero wait status: 11
Parse errors: Bad plan. You planned 3 tests but ran 2.
Try the same with DBD::mysql.
# export TEST_DB=DBI:mysql:database=test:host=maria3--testuser--mysecretpassword
# prove -v disconnect.t
1..3
# One
ok 1
# Two
ok 2
# Three
ok 3
ok
All tests successful.
The following code stores a 0-length string instead of NULL as expected:
$dbh->do("drop table if exists bar");
$dbh->do("create table bar (foo blob)");
my $sth = $dbh->prepare("insert into bar (foo) values (?)");
my $value = undef;
$sth->bind_param(1, $value, DBI::SQL_BINARY);
$sth->execute();
As reported by the auto-build tools of openSUSE Tumbleweed, I cloned the git repo on Tumbleweed and was able to reproduce/confirm the failures
Linux 5.14.6-2-default [openSUSE Tumbleweed 20211001] HP ZBook 15G3 Core(TM) i7-6820HQ CPU @ 2.70GHz/2700(8 cores) x86_64 32017 Mb
libmariadb3-3.2.3-78.14.x86_64
libmariadbd19-10.6.4-3.5.x86_64
libmariadbd-devel-10.6.4-3.5.x86_64
libmariadb-devel-3.2.3-78.14.x86_64
mariadb-10.6.4-3.5.x86_64
mariadb-bench-10.6.4-3.5.x86_64
mariadb-client-10.6.4-3.5.x86_64
mariadb-connector-odbc-3.1.10-32.27.x86_64
mariadb-errormessages-10.6.4-3.5.noarch
mariadb-tools-10.6.4-3.5.x86_64
t/10connect.t ........................... 1/? # mariadb_clientinfo is: 3.2.3
# mariadb_clientversion is: 30203
# mariadb_serverversion is: 100604
# mariadb_hostinfo is: Localhost via UNIX socket
# mariadb_serverinfo is: 10.6.4-MariaDB
# mariadb_stat is: Uptime: 464 Threads: 1 Questions: 13 Slow queries: 0 Opens: 17 Open tables: 10 Queries per second avg: 0.028
# mariadb_protoinfo is: 10
# SQL_DBMS_NAME is MariaDB
# SQL_DBMS_VER is 10.06.0400
# SQL_SERVER_NAME is Localhost via UNIX socket
# SQL_DRIVER_VER is 01.21.0000
# Default storage engine is: InnoDB
# @@character_set_client is: utf8mb4
# @@character_set_connection is: utf8mb4
# @@character_set_database is: utf8mb4
# @@character_set_results is: utf8mb4
# @@character_set_server is: utf8mb4
# @@collation_connection is: utf8mb4_unicode_ci
# @@collation_database is: utf8mb4_unicode_ci
# @@collation_server is: utf8mb4_unicode_ci
# auto_reconnects_failed is: 0
# auto_reconnects_ok is: 0
t/40server_prepare.t .................... 3/29
# Failed test 'USE is not supported with mariadb_server_prepare_disable_fallback=1'
# at t/40server_prepare.t line 80.
# Looks like you failed 1 test of 29.
t/40server_prepare.t .................... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/29 subtests
t/45bind_no_backslash_escapes.t ......... 1/20
# Failed test at t/45bind_no_backslash_escapes.t line 33.
# got: ''string\string"string''string''
# expected: 'X'737472696E675C737472696E6722737472696E6727737472696E67''
# Looks like you failed 1 test of 20.
t/45bind_no_backslash_escapes.t ......... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/20 subtests
Hello,
I am having a very difficult time trying to build this module (PALI/DBD-MariaDB-1.21.tar.gz
) on CentOS 7. I'm uncertain how much information I should supply. I'm hoping it will be enough.
Install CentOS 7 (minimal install)
Install CPAN
sudo yum -y install gcc perl-CPAN
Install Linux dependencies
sudo yum install -y perl-devel
sudo yum install -y gcc
sudo yum install -y gcc-c++
sudo yum install -y glibc
sudo yum install -y glibc.i686
sudo yum install -y glibc-devel
sudo yum install -y glibc-devel.i686
sudo yum install -y openssl-devel
sudo yum install -y bzip2 bzip2-devel
Install MariaDB development libraries. Add the MariaDB yum repository by creating the file /etc/yum.repos.d/mariadb.repo
:
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.4/rhel7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
Add the repository:
sudo yum clean all
sudo yum install -y mariadb-devel mariadb-libs
Check the MariaDB configuration:
# mariadb_config
Copyright 2011-2019 MariaDB Corporation AB
Get compiler flags for using the MariaDB Connector/C.
Usage: mariadb_config [OPTIONS]
--cflags [-I/usr/include/mysql -I/usr/include/mysql/mysql]
--include [-I/usr/include/mysql -I/usr/include/mysql/mysql]
--libs [-L/usr/lib64/ -lmariadb]
--libs_r [-L/usr/lib64/ -lmariadb]
--libs_sys [-lz -ldl -lm -lpthread -lssl -lcrypto]
--version [10.4.8]
--cc_version [3.1.4]
--socket [/var/lib/mysql/mysql.sock]
--port [3306]
--plugindir [/usr/lib64/mysql/plugin]
--tlsinfo [OpenSSL 1.0.2k]
Here is the first issue I ran in to. Installing DBD::MariaDB uses the command mariadb_config
to set header files and library files (see above). One of the MariaDB library files libmariadb.a
is incorrectly named libmariadbd.a
. I resolved this by creating the following symbolic link:
ln -s /usr/lib64/libmariadbd.a /usr/lib64/libmariadb.a
Install DBI - the database independent interface for Perl:
cpan[1]> install DBI
Install DBD::MariaDB:
export DBD_MARIADB_TESTDB=mysql
export DBD_MARIADB_TESTHOST=alamode-db
export DBD_MARIADB_TESTPORT=3306
export DBD_MARIADB_TESTUSER=dbadmin
export DBD_MARIADB_TESTPASSWORD=manager
cpan[1]> install DBD::MariaDB
And now the error:
Reading '/root/.cpan/Metadata'
Database was generated on Tue, 15 Oct 2019 20:41:03 GMT
Running install for module 'DBD::MariaDB'
Checksum for /root/.cpan/sources/authors/id/P/PA/PALI/DBD-MariaDB-1.21.tar.gz ok
Scanning cache /root/.cpan/build for sizes
...................................................-------------------------DONE
DEL(1/6): /root/.cpan/build/DBI-1.642-0
DEL(2/6): /root/.cpan/build/DBI-1.642-0.yml
DEL(3/6): /root/.cpan/build/Mock-Config-0.03-0
DEL(4/6): /root/.cpan/build/Mock-Config-0.03-0.yml
DEL(5/6): /root/.cpan/build/Devel-CheckLib-1.13-0.yml
DEL(6/6): /root/.cpan/build/Devel-CheckLib-1.13-0
Configuring P/PA/PALI/DBD-MariaDB-1.21.tar.gz with Makefile.PL
I will use the following settings for compiling and testing:
cflags (mysql_config) = -I/usr/include/mysql -I/usr/include/mysql/mysql
libs (mysql_config) = -L/usr/lib64/ -lmariadb
mysql_config (guessed ) = mariadb_config
testdb (environment ) = mysql
testhost (environment ) = alamode-db
testpassword (environment ) = image
testport (environment ) = 3306
testsocket (default ) =
testuser (environment ) = dbadmin
To change these settings, see 'perl Makefile.PL --help' and
'perldoc DBD::MariaDB::INSTALL'.
Checking if libs and header files are available for compiling...
Checking if correct version of MariaDB or MySQL client is present...
Looks good.
Embedded server: not supported by client library
Client library deinitialize OpenSSL library functions: yes
Checking if your kit is complete...
Looks good
WARNING: Older versions of ExtUtils::MakeMaker may errantly install README.pod as part of this distribution. It is recommended to avoid using this path in CPAN modules.
Using DBI 1.642 (for perl 5.016003 on x86_64-linux-thread-multi) installed in /usr/local/lib64/perl5/auto/DBI/
Generating a Unix-style Makefile
Writing Makefile for DBD::MariaDB
Writing MYMETA.yml and MYMETA.json
PALI/DBD-MariaDB-1.21.tar.gz
/usr/bin/perl Makefile.PL -- OK
Running make for P/PA/PALI/DBD-MariaDB-1.21.tar.gz
cp lib/DBD/MariaDB.pod blib/lib/DBD/MariaDB.pod
cp lib/DBD/MariaDB.pm blib/lib/DBD/MariaDB.pm
cp lib/DBD/MariaDB/INSTALL.pod blib/lib/DBD/MariaDB/INSTALL.pod
Running Mkbootstrap for MariaDB ()
chmod 644 "MariaDB.bs"
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- MariaDB.bs blib/arch/auto/DBD/MariaDB/MariaDB.bs 644
"/usr/bin/perl" -p -e "s/~DRIVER~/MariaDB/g" /usr/local/lib64/perl5/auto/DBI/Driver.xst > MariaDB.xsi
"/usr/bin/perl" "/usr/share/perl5/vendor_perl/ExtUtils/xsubpp" -typemap '/usr/share/perl5/ExtUtils/typemap' MariaDB.xs > MariaDB.xsc
Warning: duplicate function definition 'do' detected in MariaDB.xs, line 104
Warning: duplicate function definition 'rows' detected in MariaDB.xs, line 229
Warning: duplicate function definition 'last_insert_id' detected in MariaDB.xs, line 248
mv MariaDB.xsc MariaDB.c
gcc -c -I/usr/local/lib64/perl5/auto/DBI -I/usr/include/mysql -I/usr/include/mysql/mysql -DHAVE_DBI_1_634 -DHAVE_DBI_1_642 -DHAVE_PROBLEM_WITH_OPENSSL -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -DVERSION=\"1.21\" -DXS_VERSION=\"1.21\" -fPIC "-I/usr/lib64/perl5/CORE" MariaDB.c
gcc -c -I/usr/local/lib64/perl5/auto/DBI -I/usr/include/mysql -I/usr/include/mysql/mysql -DHAVE_DBI_1_634 -DHAVE_DBI_1_642 -DHAVE_PROBLEM_WITH_OPENSSL -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -DVERSION=\"1.21\" -DXS_VERSION=\"1.21\" -fPIC "-I/usr/lib64/perl5/CORE" dbdimp.c
gcc -c -I/usr/local/lib64/perl5/auto/DBI -I/usr/include/mysql -I/usr/include/mysql/mysql -DHAVE_DBI_1_634 -DHAVE_DBI_1_642 -DHAVE_PROBLEM_WITH_OPENSSL -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -DVERSION=\"1.21\" -DXS_VERSION=\"1.21\" -fPIC "-I/usr/lib64/perl5/CORE" socket.c
rm -f blib/arch/auto/DBD/MariaDB/MariaDB.so
gcc -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wl,-z,relro MariaDB.o dbdimp.o socket.o -o blib/arch/auto/DBD/MariaDB/MariaDB.so \
-L/usr/lib64/ -lmariadb \
chmod 755 blib/arch/auto/DBD/MariaDB/MariaDB.so
Manifying 2 pod documents
PALI/DBD-MariaDB-1.21.tar.gz
/usr/bin/make -- OK
Running make test for PALI/DBD-MariaDB-1.21.tar.gz
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- MariaDB.bs blib/arch/auto/DBD/MariaDB/MariaDB.bs 644
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00base.t .............................. 1/7 Bailout called. Further testing stopped: Unable to load DBD::MariaDB: Can't load '/root/.cpan/build/DBD-MariaDB-1.21-5/blib/arch/auto/DBD/MariaDB/MariaDB.so' for module DBD::MariaDB: /root/.cpan/build/DBD-MariaDB-1.21-5/blib/arch/auto/DBD/MariaDB/MariaDB.so: undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE at /usr/lib64/perl5/DynaLoader.pm line 190. at t/00base.t line 18. Compilation failed in require at t/00base.t line 18. BEGIN failed--compilation aborted at t/00base.t line 18.
FAILED--Further testing stopped: Unable to load DBD::MariaDB: Can't load '/root/.cpan/build/DBD-MariaDB-1.21-5/blib/arch/auto/DBD/MariaDB/MariaDB.so' for module DBD::MariaDB: /root/.cpan/build/DBD-MariaDB-1.21-5/blib/arch/auto/DBD/MariaDB/MariaDB.so: undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE at /usr/lib64/perl5/DynaLoader.pm line 190. at t/00base.t line 18. Compilation failed in require at t/00base.t line 18. BEGIN failed--compilation aborted at t/00base.t line 18.
make: *** [test_dynamic] Error 255
Lockfile removed.
PALI/DBD-MariaDB-1.21.tar.gz
/usr/bin/make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports PALI/DBD-MariaDB-1.21.tar.gz
Failed during this command:
PALI/DBD-MariaDB-1.21.tar.gz : make_test NO
t/40types.t ............................. 41/78
# Failed test at t/40types.t line 78.
# Structures begin differing at:
# $got->[0][0] = '2.10000000000000009'
# $expected->[0][0] = '2.1'
# Looks like you failed 1 test of 78.
t/40types.t ............................. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/78 subtests
with patch
diff --git a/t/40types.t b/t/40types.t
index b92e0aa..8fc272a 100644
--- a/t/40types.t
+++ b/t/40types.t
@@ -67,7 +67,7 @@ ok($dbh->do(qq{DROP TABLE t1}), "cleaning up");
ok($dbh->do(qq{CREATE TABLE t1 (num DOUBLE)}), "creating table");
$sth= $dbh->prepare("INSERT INTO t1 VALUES (?)");
-ok($sth->bind_param(1, 2.1, DBI::SQL_DOUBLE), "binding parameter");
+ok($sth->bind_param(1, 2.125, DBI::SQL_DOUBLE), "binding parameter");
ok($sth->execute(), "inserting data");
ok($sth->finish);
ok($sth->bind_param(1, -1, DBI::SQL_DOUBLE), "binding parameter");
@@ -75,7 +75,7 @@ ok($sth->execute(), "inserting data");
ok($sth->finish);
my $ret = $dbh->selectall_arrayref("SELECT * FROM t1");
-is_deeply($ret, [ [2.1], [-1] ]);
+is_deeply($ret, [ [2.125], [-1] ]);
$sv = svref_2object(\$ret->[0]->[0]);
ok($sv->FLAGS & SVf_NOK, "scalar is double");
→
t/40types.t ............................. ok
If an insert/update statement contains a (unquoted) column name which itself contains the string limit
this column and all following columns of type enum within the same query are getting the wrong value: the enum value is interpreted as the enum index (as if the bind type is set to integer).
Code to reproduce:
my $limits = 500;
my $flag = 1;
$dbh->do('CREATE TABLE IF NOT EXISTS table1 ( id INT(10) PRIMARY KEY AUTO_INCREMENT, limits INT(10), flag ENUM("9","0","1") )');
$dbh->do('INSERT INTO table1 SET limits=?, flag=?', undef, $limits, $flag);
my ($set_flag) = $dbh->selectrow_array('SELECT flag FROM table1 WHERE id=?', undef, $dbh->last_insert_id);
print "setting $flag => $set_flag\n";
Instead of $flag
and $set_flag
being equal, $set_flag
has the value 9 (value at index 1).
However, my tests have shown that the enum value is correct if:
flag
comes before the column limits
in the querylimits
is quoted: `limits`
limit
is selectedset flag=1
instead of set flag=?
)Also, the behavior was apparently introduced with DBD::MariaDB, I could not reproduce it with DBD::mysql (4.050).
MariaDB Server: 10.11.6 (1:10.11.6-0+deb12u1)
DBD::MariaDB: 1.22 (1.22-1+b1)
DBI: 1.643 (1.643-4)
My first attempt to switch from DBD::mysql to DBD::MariaDB was stymied by the errors MySQL server has gone away
and Can't locate object method "execute" via package "1" (perhaps you forgot to load "1"?)
.
I'm not sure where to even begin troubleshooting this issue, but switching back to DBD::mysql "fixed" the problem.
This is most likely something that we're doing in a non-standard way, but I would appreciate any pointers in what to look for.
Replicated with both MariaDB 10.3 and 10.4.
Will reliably get a segfault 1 in 2 to 1 in 4 times, when calling ping on a db handle after calling disconnect on it with latest DBD::MariaDB and mariadb 10.3 or 10.4 on debian buster, likely to be same on debian stretch. This was with auto_reconnect flag set.
my $dbh = DBI->connect("dbi:mysql:$dbname;host=localhost",$user, $password);
$dbh->disconnect();
ok( ! $dbh->ping(), 'dbh is disconnected and did not segv');
done_testing();
Hi.
This may or may not be related to #151, but the following test fails with DBD::MariaDB, though it passes with DBD::mysql. Is this an intended change?
use strict;
use warnings;
use Test::More;
use DBI;
ok my $dbh = DBI->connect("dbi:MariaDB:test", $ENV{DB_USER}, $ENV{DB_PASS}, {
AutoCommit => 1,
RaiseError => 1,
PrintError => 0,
AutoInactiveDestroy => 1,
});
ok $dbh->ping, "ping";
if (my $pid = fork()) {
exit;
}
ok $dbh->ping, "ping after fork?"; ## failing
done_testing;
I am storing DB credentials into a text file and tell the driver via the DSN string to read them. In MySQL this DSN string worked:
DBI:mysql:mysql_read_default_file=config/mysql.credentials;mysql_read_default_group=client;
with said file to contain this:
[client]
user=test
password=apass
Now, I am migrating to MariaDB and my adjusted DSN string is:
DBI:MariaDB:mariadb_read_default_file=config/mysql.credentials;mariadb_read_default_group=client;
This causes an error:
failed: Access denied for user 'test'@'localhost' (using password: NO) at ...
Please note that it reads the username correctly (test
) but does not see the password field(?).
Thank you
(Edit: I have posted the same question over at PerlMonks a few days ago: https://perlmonks.org/?node_id=11155362)
If one wants to add binary BLOB (large or small) that contains UTF-8 chars then in MariaDB it bigger than original as it's inserted as UTF-8 form.
It could be encoded to correct string (base64) or as in PR #178 decoded back to Perl UTF-8 form. But which is correct way to do it?
with 8.0.22, which had changes to ROUND() the above returns 1.7 and test case fails.
I'm not sure if the mysql changes are intentional and good, or if the test case assertion now needs to become micro-point release aware and accept either 1.70 or 1.7 as valid results.
Maybe sql query or the perl syntax to compare equivalence, rather than exact string. I don't speak perl.
Grep for ROUND() in https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-22.html
Hello,
Running Strawberry Perl 5.30.2 64 bit, I noticed the following message.
C:\home\sunlight2>cpan PALI/DBD-MariaDB-1.22.tar.gz
(snip)
Warning: duplicate function definition 'do' detected in MariaDB.xs, line 104
Warning: duplicate function definition 'rows' detected in MariaDB.xs, line 229
Warning: duplicate function definition 'last_insert_id' detected in MariaDB.xs, line 248
(snip)
Thank you,
Cloned from #164 to separate the two issues, as proposed by @pali:
Both @Tux on OpenSUSEand and me on Debian see failures in t/40server_prepare.t:
# Failed test 'USE is not supported with mariadb_server_prepare_disable_fallback=1'
# at t/40server_prepare.t line 80.
# Looks like you failed 1 test of 29.
t/40server_prepare.t ....................
1..29
ok 1 - connecting
ok 2 - making slate clean
ok 3 - creating table
ok 4 - loading data
ok 5
ok 6
ok 7 - binding parameter
ok 8 - fetching data
ok 9
ok 10 - cleaning up
ok 11 - making slate clean
ok 12 - creating test table
ok 13
ok 14 - binding int
ok 15 - binding smallint
ok 16 - binding tinyint
ok 17 - binding bigint
ok 18 - inserting data
ok 19
ok 20 - cleaning up
ok 21 - making slate clean
ok 22 - creating test table
ok 23
ok 24 - insert t3
ok 25
not ok 26 - USE is not supported with mariadb_server_prepare_disable_fallback=1
ok 27 - USE is supported with mariadb_server_prepare_disable_fallback=0
ok 28
ok 29 - cleaning up
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/29 subtests
[…]
Test Summary Report
-------------------
t/40server_prepare.t (Wstat: 256 Tests: 29 Failed: 1)
Failed test: 26
Non-zero exit status: 1
Files=90, Tests=3516, 36 wallclock secs ( 0.63 usr 0.13 sys + 6.90 cusr 0.97 csys = 8.63 CPU)
Result: FAIL
Failed 1/90 test programs. 1/3516 subtests failed.
When DBD::MariaDB (or DBD::mysql) is used to connect to a database, the perl program thereafter fails to handle SIGPIPE as expected. I do not think this is necessarily the fault of DBD::MariaDB, but this might be the best place to handle it.
Here is an example test program:
#!/usr/bin/perl
use DBI;
my $dsn = "DBI:MariaDB:database=test";
# This is also reproducible with the mysql driver.
#my $dsn = "DBI:mysql:test";
if (@ARGV && $ARGV[0] eq 'fail') {
my $dbh = DBI->connect($dsn, 'test', 'test');
# This is not necessary to reproduce the problem, but it occurs either way.
$dbh->disconnect;
if (@ARGV > 1 && $ARGV[1] eq 'fix') {
$SIG{PIPE} = undef;
}
}
# There is a race condition of some sort; for me, roughly:
# < 2200 iterations succeeds
# 2200-2500 iterations is unreliable
# > 2500 iterations fails
foreach my $i (1..10000) {
print "foo\n";
}
Without any arguments, the program does not connect and behaves as expected:
$ ./test.pl | head -n 1
foo
The program prints lines until the pipe closes, then exits cleanly.
When directed to, the program will fail by connecting (and disconnecting) before printing lines:
$ ./test.pl fail | head -n 1
foo
Unable to flush stdout: Broken pipe
This message is described here:
https://stackoverflow.com/questions/50507849/weird-error-after-perl-upgrade-unable-to-flush-stdout
An strace reveals that SIGPIPE is indeed being ignored:
$ grep -E 'SIGPIPE|EPIPE' /tmp/strace-bad.log
368030 rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f695a1ac920}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
368030 write(1, "foo\nfoo\nfoo\nfoo\nfoo\nfoo\nfoo\nfoo\n"..., 8192) = -1 EPIPE (Broken pipe)
368030 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=368030, si_uid=1000} ---
368030 write(1, "foo\nfoo\nfoo\nfoo\nfoo\nfoo\nfoo\nfoo\n"..., 8192) = -1 EPIPE (Broken pipe)
368030 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=368030, si_uid=1000} ---
368030 write(1, "foo\nfoo\nfoo\nfoo\nfoo\nfoo\nfoo\nfoo\n"..., 8192) = -1 EPIPE (Broken pipe)
368030 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=368030, si_uid=1000} ---
368030 rt_sigaction(SIGPIPE, NULL, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f695a1ac920}, 8) = 0
368030 write(1, "foo\nfoo\nfoo\nfoo\nfoo\nfoo\nfoo\nfoo\n"..., 7232) = -1 EPIPE (Broken pipe)
368030 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=368030, si_uid=1000} ---
This appears to be coming from this commit in the C connector:
mariadb-corporation/mariadb-connector-c@1cefbbe#diff-478b1bbb2170532b687be58bd28e9850ccc0b9a6aec137eb8fff7b8e6d1107bbR3460
I can't tell what is the reason for this behavior; the commit message is rather cryptic.
The test program demonstrates good behavior again after resetting the default action for SIGPIPE:
$ ./test.pl fail fix | head -n 1
foo
This is about as far as I can troubleshoot the issue myself; I think somebody more familiar with the C connector would need to either:
a. Tell me this is bad behavior and I should file a bug upstream for the C connector.
b. Work around this behavior be saving/resetting the SIGPIPE action within DBD::MariaDB
Thanks,
Corey
DBD::mysql has mysql_enable_utf8 but missing for mariadb which causing issues in backward compatibility.
cpanp
t DBD::MariaDB
Testing DBD::MariaDB (1.00)
...
/opt/perl5/perls/perl-5.26.1/lib/5.26.1/x86_64-linux/CORE/perl.h:738:13: fatal error: xlocale.h: No such file or directory
# include <xlocale.h>
^~~~~~~~~~~
compilation terminated.
make: *** [Makefile:352: MariaDB.o] Error 1
Found the page https://ahelpme.com/linux/compiling/glibc-2-26-and-failure-to-compile-because-of-xlocale-h/ saying:
Since release of glibc 2.26 there is no xlocale.h file any more, because there was never intended to be as separate file! According to the Release notes of glibc 2.26 this file
was a strict subset of the standard header locale.h
Apparently this file had had to be used only internally for the glibc, but many programs used it directly and now they fail to compile with:
-cut-
By the advice from the same page (ln -s /usr/include/locale.h /usr/include/xlocale.h) I got DBD::MariaDB successfully compiled and passed tests, but probably would be nice not to have to do that and rely that there is root that could create that link.
Thanks
I am migrating my code to MariaDB from MySQL. Previously I could pass these options to the driver via connect()
's last argument which is a hashref of options:
connect("DBI:mysql:database=testdb", $user, $pass, {'mysql_enable_utf8mb4' => 1, 'mysql_enable_utf8' => 1, 'RaiseError' => 1, 'PrintError' => 1});
But I get an error that neither mysql_enable_utf8mb4
nor mysql_enable_utf8
are recognised when I switch to the MariaDB driver connect("DBI:MariaDB:...", ...)
.
Do I still need to use these options when my DB contains unicode strings (greek etc.)?
Thank you
DBD::MariaDB $dbh->statistics_info
method is untested. There are missing unit tests that DBD::MariaDB implementation is correct.
The following example displays Active: no
and has no results:
my $dbh = DBI->connect(...);
my $sth = $dbh->prepare('SELECT id FROM sometable');
$sth->{'mariadb_use_result'} = 1;
$sth->execute();
print 'Active: ', $sth->{'Active'} ? 'yes' : 'no', "\n";
while (my $id = $sth->fetchrow_array()) {
print $id, "\n";
}
$dbh->disconnect()
It works fine without mariadb_use_result
. It works fine with DBD::mysql
, both with and without mysql_use_result
.
It might be related to 4f47a06. The execute()
call returns 0E0
rows, but with mariadb_use_results
this doesn't mean that there are no results.
Trace:
DBI::db=HASH(0x13cffc0) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI 1.642-ithread (pid 7788)
-> prepare for DBD::MariaDB::db (DBI::db=HASH(0x13cff30)~0x13cffc0 'SELECT id FROM sometable') thr#9fb260
>> func DISPATCH (DBI::db=HASH(0x13cffc0) rc1/2 @2 g2 ima6 pid#7788) at /perlpath/DBD/MariaDB.pm line 180 via at test.pl line 26
1 -> _async_check for DBD::MariaDB::db (DBI::db=HASH(0x13cffc0)~INNER) thr#9fb260
1 <- _async_check= ( 1 ) [1 items] at /perlpath/DBD/MariaDB.pm line 180 via at test.pl line 26
New 'DBI::st' (for DBD::MariaDB::st, parent=DBI::db=HASH(0x13cffc0), id=undef)
dbih_setup_handle(DBI::st=HASH(0x13cfa08)=>DBI::st=HASH(0xb00bc0), DBD::MariaDB::st, 11fb088, Null!)
dbih_make_com(DBI::db=HASH(0x13cffc0), feb8f0, DBD::MariaDB::st, 464, 0) thr#9fb260
dbih_setup_attrib(DBI::st=HASH(0xb00bc0), Err, DBI::db=HASH(0x13cffc0)) SCALAR(0x11faf98) (already defined)
dbih_setup_attrib(DBI::st=HASH(0xb00bc0), State, DBI::db=HASH(0x13cffc0)) SCALAR(0x11faff8) (already defined)
dbih_setup_attrib(DBI::st=HASH(0xb00bc0), Errstr, DBI::db=HASH(0x13cffc0)) SCALAR(0x11fafc8) (already defined)
dbih_setup_attrib(DBI::st=HASH(0xb00bc0), TraceLevel, DBI::db=HASH(0x13cffc0)) 9 (already defined)
dbih_setup_attrib(DBI::st=HASH(0xb00bc0), FetchHashKeyName, DBI::db=HASH(0x13cffc0)) 'NAME_uc' (already defined)
dbih_setup_attrib(DBI::st=HASH(0xb00bc0), HandleSetErr, DBI::db=HASH(0x13cffc0)) undef (not defined)
dbih_setup_attrib(DBI::st=HASH(0xb00bc0), HandleError, DBI::db=HASH(0x13cffc0)) CODE(0x137f710) (already defined)
dbih_setup_attrib(DBI::st=HASH(0xb00bc0), ReadOnly, DBI::db=HASH(0x13cffc0)) 1 (already defined)
dbih_setup_attrib(DBI::st=HASH(0xb00bc0), Profile, DBI::db=HASH(0x13cffc0)) undef (not defined)
-> mariadb_st_prepare_sv MYSQL_VERSION_ID 100505, SQL statement: SELECT id FROM sometable
>- mariadb_st_free_result_sets
<- mariadb_st_free_result_sets RC -1
<- mariadb_st_free_result_sets
>count_params statement SELECT id FROM sometable
<- mariadb_st_prepare_sv
<- prepare= ( DBI::st=HASH(0x13cfa08) ) [1 items] at test.pl line 26
-> STORE for DBD::MariaDB::st (DBI::st=HASH(0xb00bc0)~INNER 'mariadb_use_result' 1 (magic-r:p)) thr#9fb260
-> mariadb_st_STORE_attrib for 11fb0a0, key mariadb_use_result
<- mariadb_st_STORE_attrib for 11fb0a0, result 1
<- STORE= ( 1 ) [1 items] at test.pl line 28
-> execute for DBD::MariaDB::st (DBI::st=HASH(0x13cfa08)~0xb00bc0) thr#9fb260
-> mariadb_st_execute_iv for 11fb0a0
>- mariadb_st_free_result_sets
<- mariadb_st_free_result_sets RC -1
<- mariadb_st_free_result_sets
mariadb_st_internal_execute MYSQL_VERSION_ID 100505
>parse_params statement SELECT id FROM sometable
<- mariadb_st_execute_iv returning imp_sth->row_num 0
<- execute= ( '0E0' ) [1 items] at test.pl line 29
-> FETCH for DBD::MariaDB::st (DBI::st=HASH(0xb00bc0)~INNER 'Active') thr#9fb260
-> mariadb_st_FETCH_attrib for 11fb0a0, key Active
.. FETCH DBI::st=HASH(0xb00bc0) 'Active' = ''
<- FETCH= ( '' ) [1 items] at test.pl line 30
Active: no
-> fetchrow_array for DBD::MariaDB::st (DBI::st=HASH(0x13cfa08)~0xb00bc0) thr#9fb260
-> mariadb_st_fetch
<- fetchrow_array= ( undef ) [1 items] at test.pl line 31
-> disconnect for DBD::MariaDB::db (DBI::db=HASH(0x13cff30)~0x13cffc0) thr#9fb260
mariadb_db_close_mysql: imp_dbh=feb8f0 pmysql=16ba410
>> FETCH DISPATCH (DBI::db=HASH(0x13cffc0) rc2/3 @2 g2 ima404 pid#7788) at test.pl line 34
1 <> FETCH= ( [ DBI::st=HASH(0x13cfa08) ] ) [1 items] ('ChildHandles' from cache) at test.pl line 34
<- disconnect= ( 1 ) [1 items] at test.pl line 34
-> DESTROY for DBD::MariaDB::st (DBI::st=HASH(0xb00bc0)~INNER) thr#9fb260
--> mariadb_st_finish
<-- mariadb_st_finish
<- DESTROY= ( undef ) [1 items] at test.pl line 34 via at test.pl line 34
-> DESTROY for DBD::MariaDB::db (DBI::db=HASH(0x13cffc0)~INNER) thr#9fb260
<- DESTROY= ( undef ) [1 items]
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.