perl5-dbi / dbd-mariadb Goto Github PK

View Code? Open in Web Editor NEW

31.0 31.0 18.0 2.84 MB

Perl MariaDB driver

License: Other

Perl 54.87% C 45.13%

database-access database-connector dbd dbi mariadb mariadb-connector perl perl-database-interface perl5

dbd-mariadb's People

Contributors

Stargazers

Watchers

Forkers

pali 9eor9 iangilfillan grinnz rzl kabanoid marketajakubovicova janchochol rkleemann choroba mcermak hakonhagland clayne rovo89 mkaindl illuusio gilius38

dbd-mariadb's Issues

empty string inserted instead of NULL for binary values

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();

utf8mb4 problems

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)

Can't disconnect and connect again

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.

xlocale.h

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

2.1 is not a good testing value for -Duselongdouble

https://github.com/gooddata/DBD-MariaDB/blob/8d0799ce41eb06821ba3352f3ba336dfa5e262f4/t/40types.t#L70

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

Add a missing break to 'MYSQL_TYPE_NULL' case in mariadb_st_describe()

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.

$dbh->statistics_info method does not have tests

DBD::MariaDB $dbh->statistics_info method is untested. There are missing unit tests that DBD::MariaDB implementation is correct.

Replace compile time version detection by runtime version detection

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.

Selecting from JSON columns does not decode them from UTF-8

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

Test failures with MariaDB-10.6.4 + libmariadb3-3.2.3

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

ping after fork

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;

FTBFS: t/55utf8.t fails with MariaDB 10.3.12

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

failed: SSL connection error: Enforcing SSL encryption is not supported

[feature request] Allow user/username in DSN

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";

README.pod included in distribution

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.

$sth->{TYPE} returning different values than DBD::mysql

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
   }
}

test case fails with mysql 8.0.22

https://github.com/gooddata/DBD-MariaDB/blob/9e9b5f9abf50080a17fd406425ae2f7bf35c4461/t/rt122541-decimals.t#L17

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

As of MySQL 8.0.34 and 8.1.0 's libmysqlclients deprecates MYSQL_OPT_RECONNECT

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:

DBD-MariaDB/dbdimp.c

Lines 2364 to 2371 in e81937d

 #if MYSQL_VERSION_ID >= 50013 

 { 

 my_bool reconnect = FALSE; 

 mysql_options(sock, MYSQL_OPT_RECONNECT, &reconnect); 

 } 

 #else 

 sock->reconnect = FALSE; 

 #endif

See perl5-dbi/DBD-mysql#354

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

Test MariaDB 10.5+ and MySQL 8.1+ server versions in Github Actions CI

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.

BUG? Can't find 'boot_DBD__MariaDB' in Windows/StrawberryPerl using distro DBD::MariaDB

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

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.

DBD::MariaDB 1.23 not updating cardinality in MariaDB 10.6.5

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.

support for mysql_enable_utf8

DBD::mysql has mysql_enable_utf8 but missing for mariadb which causing issues in backward compatibility.

Options to the driver mysql_enable_utf8mb4 and mysql_enable_utf8 are not recognised

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

`mariadb_use_result` is broken

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]

Some problems with Unicode encoding

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 (Ã¶).

Drop-in replacement for DBD::mysql?

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?

Handshake error connecting from client 8.0.17 to mysql server 5.1.7

t/40server_prepare.t fails

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.

please release DBD-MariaDB on CPAN

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.

SIGPIPE ignored, resulting in: "Unable to flush stdout: Broken pipe"

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

perl.h:175:16: error: 'my_perl' undeclared

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

MySQL server has gone away

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.

Spelling error

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.

BLOB as parameter in execute

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?

DBD-MariaDB does not check "Active" on database handles when preparing / executing

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

segfault on debian buster calling ping after disconnect

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();

DBD::MariaDB does not exist on cpan

The links on the README page to DBD::MariaDB are broken, and cpan is not aware of any module named DBD::MariaDB.

Backward compatibility with DBD::mysql

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

mariadb_st_finish() does not check mariadb_db_async_result() failure

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.

Passing credentials via options file fails to read password (mariadb_read_default_file)

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)

DBD-MariaDB-1.22: Build warnings

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,

Cannot build with CentOS 7

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

unable to get return value from MariaDB via perl DBI

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.

De-initializing DBI DR structure de-initialize OpenSSL library

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)

	#if MYSQL_VERSION_ID >= 50013
	{
	my_bool reconnect = FALSE;
	mysql_options(sock, MYSQL_OPT_RECONNECT, &reconnect);
	}
	#else
	sock->reconnect = FALSE;
	#endif

perl5-dbi / dbd-mariadb Goto Github PK

dbd-mariadb's People

Contributors

Stargazers

Watchers

Forkers

dbd-mariadb's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs