DBD::mysql 4.032 released
Dear Perl and MySQL community, We're pleased to announce the release of DBD::mysql 4.032! The changes, per ChangeLog features from test releases 4.032_01 and 4_032_02 as well as git log: * Daniël van Eeden and Eric Herman (Booking.com) - 5.6.6 the connection attributes - support for utf8mb4 - documentation for new features - code efficiency improvements - test fixes * Fixed test rt88006-bit-prepare on MyISAM storage (Reported both in RT102657 and by Scimon on github) * Fix for https://rt.cpan.org/Public/Bug/Display.html?id=102717 Fritz Friedrich Haubensak (hsk AT fli-leibniz DOT de) Vielen Danken! * Corrected name ofINSTALL.pm in POD David Farrell davidnmfarrell AT gmail DOT com * Documentation improvements (Rob Van Dam rvandam AT gmail DOT com) Special thanks to Daniel Daniël van Eeden, Eric Herman, Rob Van Dam, Friedrich Haubensak, and Michiel Beijen! Regards, Patrick and Michiel CPAN: https://metacpan.org/release/DBD-mysql https://metacpan.org/release/DBD-mysql Github: https://github.com/perl5-dbi/DBD-mysql https://github.com/perl5-dbi/DBD-mysql
Re: SQL::Parser schema patches
Excellent! We found the github repo. We will be forking from there and sending a pull request with your requirements. Thanks for the prompt answer, gonzalo On Tue, Jul 21, 2015 at 10:37 AM, Jens Rehsack rehs...@cpan.org wrote: Hi Gonzalo, Am 21.07.2015 um 15:29 schrieb Gonzalo Barco gbarc...@gmail.com: Hi, A work collegue has made some mods to SQL::Parser and is eager to commit the to the official code base. The patches should be rebased to latest release and should have tests (either to prove what fails before or what feature now works better/correctly) for quick goal. The patches must not cause existing tests to fail (regression). Could we send a patch via mail? You can send them via e-Mail, but please not to my private e-Mail. Send them to dbi-dev@ mailing list, RT bug-tracker or github issue tracker. Best regards, -- Jens Rehsack - rehs...@gmail.com
[perl5-dbi/dbi] 7b5a1d: Change return type of dbd_st_execute, dbd_st_rows,...
Branch: refs/heads/master
Home: https://github.com/perl5-dbi/dbi
Commit: 7b5a1d831740bdd121b301352e7b566e40181fa8
https://github.com/perl5-dbi/dbi/commit/7b5a1d831740bdd121b301352e7b566e40181fa8
Author: Tim Bunce tim.bu...@pobox.com
Date: 2015-07-21 (Tue, 21 Jul 2015)
Changed paths:
M dbd_xsh.h
Log Message:
---
Change return type of dbd_st_execute, dbd_st_rows, and dbd_db_do4 from int to
IV
Commit: db4daeb3611f3f2549bf012422565564556f4608
https://github.com/perl5-dbi/dbi/commit/db4daeb3611f3f2549bf012422565564556f4608
Author: Tim Bunce tim.bu...@pobox.com
Date: 2015-07-21 (Tue, 21 Jul 2015)
Changed paths:
M Changes
M DBI.pm
Log Message:
---
Added support for tables('', '', '', '%') special case (Martin J. Evans)
Compare: https://github.com/perl5-dbi/dbi/compare/397c1be485b6...db4daeb3611f
Re: DBD::mysql Re: Why is selectrow_hashref complaining about a fetch without execute?
On Tue, Jul 21, 2015 at 01:33:34PM +0100, Martin J. Evans wrote:
Long, sorry.
No problem. The whole topic is a bit of a mess.
On 20/07/15 18:00, Tim Bunce wrote:
On Mon, Jul 20, 2015 at 02:54:53PM +0100, Martin J. Evans wrote:
On 20/07/15 14:15, Tim Bunce wrote:
I think that would work for me - I'm happy to test it our here if you want
to give it a go.
IIRC, when this was last discussed the problem is that some drivers
might not set DBIc_ROW_COUNT so you can't just use DBIc_ROW_COUNT.
Hence the check that DBIc_ROW_COUNT is not zero. Since the DBI code sets
it to zero before the call, if it's non-zero after the call we can be
sure that the driver has set it.
In fact, I just checked, and DBD::ODBC does not seem to call
DBIc_ROW_COUNT other than to set it to 0 in ODBC.xsi (which is code
from DBI anyway). Does that sound right?
Nope. Is it setting the underlying structure member directly?
no. All it does is it has a RowCount member in its own imp_sth_st structure
which is a SQLLEN (64 bits on 64 bit machines and 32 on 32). Then it:
o dbd_db_execute returns the number of rows or -1 or -2 (error)
At the end of dbd_st_execute if the affected rows is bigger than INT_MAX
and warnings are
on, it warns the rowcount has been truncated and changes the row count to
INT_MAX.
That's reasonable. Hopefully we can do better though.
o has odbc_st_rows (because it is defined in dbd_xsh.h and I believed
you needed to implement most of these in the DBD) which casts the
internal RowCount to an int as odbc_st_rows is defined as returning an int.
The DBI provides a default rows method, in C, that returns DBIc_ROW_COUNT.
So a driver that stores the row count in DBIc_ROW_COUNT doesn't need to
provide a rows method at all (if all it needs to do is return the count).
That translates into not defining the dbd_st_rows macro. If that's not
defined then the rows method in Driver.xst won't get compiled in so
there'll be no call to a driver-provided dbd_st_rows.
DBD::ODBC also has its own odbc_rows which returns an IV to workaround this
issue in DBI when I found it back in 2012.
If DBD::ODBC switched to using DBIc_ROW_COUNT then you could remove
dbd_st_rows/odbc_rows. (It seems unlikely that sizeof(IV) would ever me
less than sizeof(SQLLEN) but that might be worth an assertion anyway.)
Looking at 'do' in DBI.pm it just does:
sub do {
my($dbh, $statement, $attr, @params) = @_;
my $sth = $dbh-prepare($statement, $attr) or return undef;
$sth-execute(@params) or return undef;
my $rows = $sth-rows;
($rows == 0) ? 0E0 : $rows;
}
so doesn't that just end up in dbd_st_rows?
Assuming the driver is using that default do() method, then it'll
end up in dbd_st_rows if the driver has defined a dbd_st_rows macro,
else it'll end up in the DBI's default rows() method.
If a driver is supposed to set DBIc_ROW_COUNT I'd rather change the
drivers I maintain to do that especially since in ODBC and 64bit
SQLRowCount already returns a 64 bit value.
Yeap. That's best.
See above, I don't see how that fits in right now.
Is the only outstanding issue now the 'int' return type on some various
dbd_st_* functions?
I tried to check my assumptions and this is what I found:
o DBD::ODBC has its own 'do' method because it can use SQLExecDirect instead
of prepare/execute. This returns the rows affected correctly as it returns an
SV created from the SQLLEN RowCount. So, the do method in DBI (shown above)
is neither here nor there for DBD::ODBC.
o DBD::ODBC has a dbd_st_rows which seems to get called if someone calls the
rows method.
dbd_st_rows is defined in dbd_xsh.h as returning an int so this is wrong.
And can simply be removed, per the above.
o 'execute' or dbd_st_execute returns the rows and is again defined in
dbd_xsh as returning an int.
I don't see where DBIc_ROW_COUNT comes in unless you are saying every time a
DBD discovers the row count it should call DBIc_ROW_COUNT macro.
DBIc_ROW_COUNT is just a macro for an IV in the imp_sth structure. Most,
if not all, compiled drivers that aren't using DBIc_ROW_COUNT are simply
using their own integer element in the imp_sth structure. In the case of
DBD::Pg that's declared as a plain int type.
So I'd hope and expect a driver can simply use DBIc_ROW_COUNT _instead of_
whatever it's currently using.
I also noticed something I should have seen before: dbd_st_rows() is
defined as returning an int. I _think_ it would be safe to change the
definition to returning an IV since it's only used internally by drivers
via the Driver.xst template file that does:
XST_mIV(0, dbd_st_rows(sth, imp_sth));
Unless I'm missing something I think that will break most drivers as when I
grepped cpan I found most drivers implement dbd_st_rows as:
int dbd_st_rows {
code
}
[Sigh] I'm getting a bit rusty at C. I'd forgotten that hurdle.
The int return type affects
Re: SQL::Parser schema patches
Hi Gonzalo, Am 21.07.2015 um 15:29 schrieb Gonzalo Barco gbarc...@gmail.com: Hi, A work collegue has made some mods to SQL::Parser and is eager to commit the to the official code base. The patches should be rebased to latest release and should have tests (either to prove what fails before or what feature now works better/correctly) for quick goal. The patches must not cause existing tests to fail (regression). Could we send a patch via mail? You can send them via e-Mail, but please not to my private e-Mail. Send them to dbi-dev@ mailing list, RT bug-tracker or github issue tracker. Best regards, -- Jens Rehsack - rehs...@gmail.com
Re: DBD::mysql Re: Why is selectrow_hashref complaining about a fetch without execute?
Long, sorry.
On 20/07/15 18:00, Tim Bunce wrote:
On Mon, Jul 20, 2015 at 02:54:53PM +0100, Martin J. Evans wrote:
On 20/07/15 14:15, Tim Bunce wrote:
I think that would work for me - I'm happy to test it our here if you want to
give it a go.
IIRC, when this was last discussed the problem is that some drivers
might not set DBIc_ROW_COUNT so you can't just use DBIc_ROW_COUNT.
Hence the check that DBIc_ROW_COUNT is not zero. Since the DBI code sets
it to zero before the call, if it's non-zero after the call we can be
sure that the driver has set it.
In fact, I just checked, and DBD::ODBC does not seem to call
DBIc_ROW_COUNT other than to set it to 0 in ODBC.xsi (which is code
from DBI anyway). Does that sound right?
Nope. Is it setting the underlying structure member directly?
no. All it does is it has a RowCount member in its own imp_sth_st structure
which is a SQLLEN (64 bits on 64 bit machines and 32 on 32). Then it:
o dbd_db_execute returns the number of rows or -1 or -2 (error)
At the end of dbd_st_execute if the affected rows is bigger than INT_MAX and
warnings are
on, it warns the rowcount has been truncated and changes the row count to
INT_MAX.
o has odbc_st_rows (because it is defined in dbd_xsh.h and I believed you
needed to implement most of these in the DBD) which casts the internal RowCount
to an int as odbc_st_rows is defined as returning an int.
DBD::ODBC also has its own odbc_rows which returns an IV to workaround this
issue in DBI when I found it back in 2012.
Note dbd_xsh.h defines dbd_st_rows and dbd_st_execute as returning ints.
Looking at 'do' in DBI.pm it just does:
sub do {
my($dbh, $statement, $attr, @params) = @_;
my $sth = $dbh-prepare($statement, $attr) or return undef;
$sth-execute(@params) or return undef;
my $rows = $sth-rows;
($rows == 0) ? 0E0 : $rows;
}
so doesn't that just end up in dbd_st_rows?
If a driver is supposed to set DBIc_ROW_COUNT I'd rather change the
drivers I maintain to do that especially since in ODBC and 64bit
SQLRowCount already returns a 64 bit value.
Yeap. That's best.
See above, I don't see how that fits in right now.
I tried to check my assumptions and this is what I found:
o DBD::ODBC has its own 'do' method because it can use SQLExecDirect instead of
prepare/execute. This returns the rows affected correctly as it returns an SV
created from the SQLLEN RowCount. So, the do method in DBI (shown above) is
neither here nor there for DBD::ODBC.
o DBD::ODBC has a dbd_st_rows which seems to get called if someone calls the
rows method.
dbd_st_rows is defined in dbd_xsh.h as returning an int so this is wrong.
o 'execute' or dbd_st_execute returns the rows and is again defined in dbd_xsh
as returning an int.
I don't see where DBIc_ROW_COUNT comes in unless you are saying every time a
DBD discovers the row count it should call DBIc_ROW_COUNT macro.
Is there some docs on that or perhaps you could just tell me or point
me at a driver that does it correctly.
No docs, sadly. And I'm not aware of any drivers that do.
I took a look at DBD:Pg and that uses it's own 'rows' structure
member which is defined as an int, and int is used in the code.
I also noticed something I should have seen before: dbd_st_rows() is
defined as returning an int. I _think_ it would be safe to change the
definition to returning an IV since it's only used internally by drivers
via the Driver.xst template file that does:
XST_mIV(0, dbd_st_rows(sth, imp_sth));
Unless I'm missing something I think that will break most drivers as when I
grepped cpan I found most drivers implement dbd_st_rows as:
int dbd_st_rows {
code
}
I'm having a frustrating day so far so perhaps have lost the ability to read
diffs and C but in your change at
https://github.com/perl5-dbi/dbi/commit/29f6b9b76e9c637be31cb80f1a262ff68b42ef43#diff-cb6af96fe009d6f8d9d682415e1ab755
if retval0 (checked above) I don't see where the checked above bit is.
it looks like:
if (retval == 0)
..
else if (retval == -1)
..
else if (retval = -2)
..
else
new stuff here
retval could still be negative just not -1 or -2
The else if (retval = -2) covers other negative values, doesn't it?
my mistake, as I said, I was not having a good day.
Also, maybe a little picky but the comment and DBIc_ROW_COUNT0 does not
match the code.
Yeah, I was in two minds about that. I'll use DBIc_ROW_COUNT0 in
practice, but !=0 seemed a better fit for the experimental warning.
If no DBDs use DBIc_ROW_COUNT then that warning you've put in will do
nothing. I'd like to see a driver which does use DBIc_ROW_COUNT and if
there are none I'm happy to change DBD::ODBC initially to a) test the
diff you just applied and b) test the suggested fix.
That would be great. Thank you Martin!
Tim.
I'll happily make any changes you suggest and can test any changes you want to
try out in DBI but I think there are still some issues to discuss
Re: DBD::mysql Re: Why is selectrow_hashref complaining about a fetch without execute?
On 21/07/15 15:03, Tim Bunce wrote:
On Tue, Jul 21, 2015 at 01:33:34PM +0100, Martin J. Evans wrote:
Long, sorry.
No problem. The whole topic is a bit of a mess.
On 20/07/15 18:00, Tim Bunce wrote:
On Mon, Jul 20, 2015 at 02:54:53PM +0100, Martin J. Evans wrote:
On 20/07/15 14:15, Tim Bunce wrote:
I think that would work for me - I'm happy to test it our here if you want to
give it a go.
IIRC, when this was last discussed the problem is that some drivers
might not set DBIc_ROW_COUNT so you can't just use DBIc_ROW_COUNT.
Hence the check that DBIc_ROW_COUNT is not zero. Since the DBI code sets
it to zero before the call, if it's non-zero after the call we can be
sure that the driver has set it.
In fact, I just checked, and DBD::ODBC does not seem to call
DBIc_ROW_COUNT other than to set it to 0 in ODBC.xsi (which is code
from DBI anyway). Does that sound right?
Nope. Is it setting the underlying structure member directly?
no. All it does is it has a RowCount member in its own imp_sth_st structure
which is a SQLLEN (64 bits on 64 bit machines and 32 on 32). Then it:
o dbd_db_execute returns the number of rows or -1 or -2 (error)
At the end of dbd_st_execute if the affected rows is bigger than INT_MAX and
warnings are
on, it warns the rowcount has been truncated and changes the row count to
INT_MAX.
That's reasonable. Hopefully we can do better though.
o has odbc_st_rows (because it is defined in dbd_xsh.h and I believed
you needed to implement most of these in the DBD) which casts the
internal RowCount to an int as odbc_st_rows is defined as returning an int.
The DBI provides a default rows method, in C, that returns DBIc_ROW_COUNT.
So a driver that stores the row count in DBIc_ROW_COUNT doesn't need to
provide a rows method at all (if all it needs to do is return the count).
That translates into not defining the dbd_st_rows macro. If that's not
defined then the rows method in Driver.xst won't get compiled in so
there'll be no call to a driver-provided dbd_st_rows.
ok, so I'll try removing dbd_st_rows and whenever I call SQLRowCount I'll use
the DBIc_ROW_COUNT macro.
DBD::ODBC also has its own odbc_rows which returns an IV to workaround this
issue in DBI when I found it back in 2012.
If DBD::ODBC switched to using DBIc_ROW_COUNT then you could remove
dbd_st_rows/odbc_rows. (It seems unlikely that sizeof(IV) would ever me
less than sizeof(SQLLEN) but that might be worth an assertion anyway.)
I will add assertion.
Looking at 'do' in DBI.pm it just does:
sub do {
my($dbh, $statement, $attr, @params) = @_;
my $sth = $dbh-prepare($statement, $attr) or return undef;
$sth-execute(@params) or return undef;
my $rows = $sth-rows;
($rows == 0) ? 0E0 : $rows;
}
so doesn't that just end up in dbd_st_rows?
Assuming the driver is using that default do() method, then it'll
end up in dbd_st_rows if the driver has defined a dbd_st_rows macro,
else it'll end up in the DBI's default rows() method.
If a driver is supposed to set DBIc_ROW_COUNT I'd rather change the
drivers I maintain to do that especially since in ODBC and 64bit
SQLRowCount already returns a 64 bit value.
Yeap. That's best.
See above, I don't see how that fits in right now.
Is the only outstanding issue now the 'int' return type on some various
dbd_st_* functions?
Yes, I believe so.
I tried to check my assumptions and this is what I found:
o DBD::ODBC has its own 'do' method because it can use SQLExecDirect instead of
prepare/execute. This returns the rows affected correctly as it returns an SV
created from the SQLLEN RowCount. So, the do method in DBI (shown above) is
neither here nor there for DBD::ODBC.
o DBD::ODBC has a dbd_st_rows which seems to get called if someone calls the
rows method.
dbd_st_rows is defined in dbd_xsh.h as returning an int so this is wrong.
And can simply be removed, per the above.
o 'execute' or dbd_st_execute returns the rows and is again defined in dbd_xsh
as returning an int.
I don't see where DBIc_ROW_COUNT comes in unless you are saying every time a
DBD discovers the row count it should call DBIc_ROW_COUNT macro.
DBIc_ROW_COUNT is just a macro for an IV in the imp_sth structure. Most,
if not all, compiled drivers that aren't using DBIc_ROW_COUNT are simply
using their own integer element in the imp_sth structure. In the case of
DBD::Pg that's declared as a plain int type.
So I'd hope and expect a driver can simply use DBIc_ROW_COUNT _instead of_
whatever it's currently using.
I also noticed something I should have seen before: dbd_st_rows() is
defined as returning an int. I _think_ it would be safe to change the
definition to returning an IV since it's only used internally by drivers
via the Driver.xst template file that does:
XST_mIV(0, dbd_st_rows(sth, imp_sth));
Unless I'm missing something I think that will break most drivers as when I
grepped cpan I found most drivers
