Grokbase Groups Perl dbi-dev May 2003
FAQ
Hello all,

I have put together a *BETA* release of DBD::mysql, and I would like to
get some feedback esp. WRT any breakage/bugs. If things look good I will
go ahead and release this as 2.1027.

The tarball is here:
http://www.remotelinux.com/rlippan/DBD-mysql-2.1027_2.tar.gz


List of Changes:

* Updated type_info_all() to be more inline with
what DBD::ODBC returns.
* Added attribute 'auto_reconnect' that allows the auto reconnect
behaviour to be toggled. Right now this attribute defaults to
ON for backward compatibility; however, the default behaviour
may change so that auto_reconnect only defaults to on
in a mod_perl env.
* Fixed a segfault with failed reconnects that were trapped in an
eval. The next tine DBD::mysql tried to reconnect, the process
would segfault.
* Added statistics attribute, 'mysql_dbd_stats' which returns
a hashref that contains 2 keys 'auto_reconnects' and
'failed_auto_reconnects'.
* Fixed bug where strings that were used in numeric
context were not getting quoted on execute(). Now all
parameters are bound as varchar by default.

**NOTE** this is a chage in behaviour that MAY cause problems
with some SQL statements. If quoted integers causes any
problems,
use bind_param(<column_id>, SQL_INTEGER) to force
a column
to be bound as an integer.

* Added get_info() method. See 'perldoc DBI' for more info
* Added column_info(). See 'perldoc DBI' for more info [Tim Bunce]

Search Discussions

  • Tim Bunce at May 29, 2003 at 9:27 am

    On Thu, May 29, 2003 at 04:28:13AM -0400, Rudy Lippan wrote:
    Hello all,

    I have put together a *BETA* release of DBD::mysql, and I would like to
    get some feedback esp. WRT any breakage/bugs. If things look good I will
    go ahead and release this as 2.1027.

    The tarball is here:
    http://www.remotelinux.com/rlippan/DBD-mysql-2.1027_2.tar.gz


    List of Changes:

    * Updated type_info_all() to be more inline with
    what DBD::ODBC returns.
    * Added attribute 'auto_reconnect' that allows the auto reconnect
    behaviour to be toggled.
    That should be 'mysql_auto_reconnect' of course.
    Right now this attribute defaults to
    ON for backward compatibility; however, the default behaviour
    may change so that auto_reconnect only defaults to on
    in a mod_perl env.
    I hope it will before the release. The current behaviour is unsafe for
    any application using locks.
    * Added statistics attribute, 'mysql_dbd_stats' which returns
    a hashref that contains 2 keys 'auto_reconnects' and
    'failed_auto_reconnects'.
    I'm a bit of a pedant when it comes to lexical ordering of things.
    I'd prefer 'auto_reconnects' and 'auto_reconnects_failed' (assuming
    auto_reconnects counts attempts, not just successes, otherwise it
    should be something like auto_reconnects_okay).
    * Fixed bug where strings that were used in numeric
    context were not getting quoted on execute(). Now all
    parameters are bound as varchar by default.

    **NOTE** this is a chage in behaviour that MAY cause problems
    with some SQL statements. If quoted integers causes any
    s/integers/integers, for example,/
    problems,
    use bind_param(<column_id>, SQL_INTEGER) to force
    a column
    to be bound as an integer.

    Thanks Rudy.

    Tim.
  • Rudy Lippan at May 30, 2003 at 4:11 pm

    On Thu, 29 May 2003, Tim Bunce wrote:
    List of Changes:

    * Updated type_info_all() to be more inline with
    what DBD::ODBC returns.
    * Added attribute 'auto_reconnect' that allows the auto reconnect
    behaviour to be toggled.
    That should be 'mysql_auto_reconnect' of course.
    Yes.
    Right now this attribute defaults to
    ON for backward compatibility; however, the default behaviour
    may change so that auto_reconnect only defaults to on
    in a mod_perl env.
    I hope it will before the release. The current behaviour is unsafe for
    any application using locks.
    OK. I agree with you. -- The reason why I left the behaviour the way
    it was is because do do that you have override the mysql library connect
    defaults.
    * Added statistics attribute, 'mysql_dbd_stats' which returns
    a hashref that contains 2 keys 'auto_reconnects' and
    'failed_auto_reconnects'.
    I'm a bit of a pedant when it comes to lexical ordering of things.
    I'd prefer 'auto_reconnects' and 'auto_reconnects_failed' (assuming
    auto_reconnects counts attempts, not just successes, otherwise it
    should be something like auto_reconnects_okay).
    OK.... It did not count attempts but rather sucesses. That is why I put
    the failed_, because I thought that made the behavour a little more
    obvious. I will change them to 'auto_reconnects_okay' and
    'auto_reconnect_failed'.
    * Fixed bug where strings that were used in numeric
    context were not getting quoted on execute(). Now all
    parameters are bound as varchar by default.

    **NOTE** this is a chage in behaviour that MAY cause problems
    with some SQL statements. If quoted integers causes any
    s/integers/integers, for example,/
    OK IC, other numberics might cause problems also. will update.


    Rudy.
  • Tim Bunce at Jun 6, 2003 at 2:13 pm

    On Fri, May 30, 2003 at 12:13:17PM -0400, Rudy Lippan wrote:
    On Thu, 29 May 2003, Tim Bunce wrote:

    Right now this attribute defaults to
    ON for backward compatibility; however, the default behaviour
    may change so that auto_reconnect only defaults to on
    in a mod_perl env.
    I hope it will before the release. The current behaviour is unsafe for
    any application using locks.
    OK. I agree with you. -- The reason why I left the behaviour the way
    it was is because do do that you have override the mysql library connect
    defaults.
    On a vagely related topic, I think mysql_client_found_rows=1 should
    also be the default.

    Right now DBD::mysql rows defaults to counting rows *physically
    changed* not just 'matched', so:

    $rows = $dbh->do("UPDATE table SET foo=7 WHERE id=42");

    will return 0 if foo already equals 7. That's very non-standard
    behaviour and very rarely wanted.

    Whereas it's far more common to want to check that $rows equals
    the number of rows you expect the qualifier (id=42) to match.

    As a case in point, Class::DBI has code to check just that, but
    it's disabled at the moment because of this issue (and that fact that
    previous DBD::mysql's could only specify mysql_client_found_rows=1
    via the dsn string and not the attribute hash parameter).

    Tim.
  • Rudy Lippan at Jun 6, 2003 at 6:55 pm

    On Fri, 6 Jun 2003, Tim Bunce wrote:
    On Fri, May 30, 2003 at 12:13:17PM -0400, Rudy Lippan wrote:
    On Thu, 29 May 2003, Tim Bunce wrote:

    Right now this attribute defaults to
    ON for backward compatibility; however, the default behaviour
    may change so that auto_reconnect only defaults to on
    in a mod_perl env.
    I hope it will before the release. The current behaviour is unsafe for
    any application using locks.
    OK. I agree with you. -- The reason why I left the behaviour the way
    it was is because do do that you have override the mysql library connect
    defaults.
    On a vagely related topic, I think mysql_client_found_rows=1 should
    also be the default.
    It can be, even in the current version. There is a compile time option
    for it, but I don't think it is documented [This should be fixed,
    though ;) ].



    From dbdimp.c:

    #ifdef MYSQL_DONT_USE_CLIENT_FOUND_ROWS
    unsigned int client_flag = 0;
    #else
    unsigned int client_flag = CLIENT_FOUND_ROWS;
    #endif



    Do you want me to flip the default and/or put this in a std attribute?

    Rudy
  • Tim Bunce at Jun 6, 2003 at 10:49 pm

    On Fri, Jun 06, 2003 at 02:56:12PM -0400, Rudy Lippan wrote:
    On Fri, 6 Jun 2003, Tim Bunce wrote:
    On Fri, May 30, 2003 at 12:13:17PM -0400, Rudy Lippan wrote:
    On Thu, 29 May 2003, Tim Bunce wrote:

    Right now this attribute defaults to
    ON for backward compatibility; however, the default behaviour
    may change so that auto_reconnect only defaults to on
    in a mod_perl env.
    I hope it will before the release. The current behaviour is unsafe for
    any application using locks.
    OK. I agree with you. -- The reason why I left the behaviour the way
    it was is because do do that you have override the mysql library connect
    defaults.
    On a vagely related topic, I think mysql_client_found_rows=1 should
    also be the default.
    It can be, even in the current version. There is a compile time option
    for it, but I don't think it is documented [This should be fixed,
    though ;) ].
    From dbdimp.c:
    #ifdef MYSQL_DONT_USE_CLIENT_FOUND_ROWS
    unsigned int client_flag = 0;
    #else
    unsigned int client_flag = CLIENT_FOUND_ROWS;
    #endif

    Do you want me to flip the default and/or put this in a std attribute?
    Both, thanks. Needs to be made clear in the change notes of course.

    Tim.
  • Rudy Lippan at Jun 9, 2003 at 5:09 am

    On Fri, 6 Jun 2003, Tim Bunce wrote:
    On Fri, Jun 06, 2003 at 02:56:12PM -0400, Rudy Lippan wrote:
    On Fri, 6 Jun 2003, Tim Bunce wrote:


    On a vagely related topic, I think mysql_client_found_rows=1 should
    also be the default.
    It can be, even in the current version. There is a compile time option
    for it, but I don't think it is documented [This should be fixed,
    though ;) ].
    From dbdimp.c:
    #ifdef MYSQL_DONT_USE_CLIENT_FOUND_ROWS
    unsigned int client_flag = 0;
    #else
    unsigned int client_flag = CLIENT_FOUND_ROWS;
    #endif

    Do you want me to flip the default and/or put this in a std attribute?
    Both, thanks. Needs to be made clear in the change notes of course.
    I changed DBD::mysql to default to CLIENT_FOUND_ROWS on connect.

    And now I remember why I did not create an attribute for it.
    CLINET_FOUND_ROWS is a connect-time option, so it does no good to create a
    dbh attribute to change the value. Oh and BTW, this is already
    configurable on the connect string 'mysql_found_rows=1'.

    Rudy
  • Tim Bunce at Jun 9, 2003 at 10:29 am

    On Mon, Jun 09, 2003 at 01:11:18AM -0400, Rudy Lippan wrote:
    On Fri, 6 Jun 2003, Tim Bunce wrote:
    On Fri, Jun 06, 2003 at 02:56:12PM -0400, Rudy Lippan wrote:
    On Fri, 6 Jun 2003, Tim Bunce wrote:


    On a vagely related topic, I think mysql_client_found_rows=1 should
    also be the default.
    It can be, even in the current version. There is a compile time option
    for it, but I don't think it is documented [This should be fixed,
    though ;) ].
    From dbdimp.c:
    #ifdef MYSQL_DONT_USE_CLIENT_FOUND_ROWS
    unsigned int client_flag = 0;
    #else
    unsigned int client_flag = CLIENT_FOUND_ROWS;
    #endif

    Do you want me to flip the default and/or put this in a std attribute?
    Both, thanks. Needs to be made clear in the change notes of course.
    I changed DBD::mysql to default to CLIENT_FOUND_ROWS on connect. Thanks.
    And now I remember why I did not create an attribute for it.
    CLINET_FOUND_ROWS is a connect-time option, so it does no good to create a
    dbh attribute to change the value.
    Ah, but you can now do it via an attribute...

    The attribute ref is passed into the dbd_db_login6() function via
    Driver.xst so attributes can be handled at connect time.

    All mysql connect-time options should be settable via connect-time
    attributes (can make them read-only after that by deleting them
    from the attribute hash and having STORE croak on them).
    Oh and BTW, this is already
    configurable on the connect string 'mysql_found_rows=1'.
    Sure, but the problem is that editing the DSN in generic code is tricky.
    (Class::DBI is an example).

    Tim.
  • Rudy Lippan at Jun 9, 2003 at 2:54 pm

    On Mon, 9 Jun 2003, Tim Bunce wrote:
    On Mon, Jun 09, 2003 at 01:11:18AM -0400, Rudy Lippan wrote:
    And now I remember why I did not create an attribute for it.
    CLINET_FOUND_ROWS is a connect-time option, so it does no good to create a
    dbh attribute to change the value.
    Ah, but you can now do it via an attribute...

    The attribute ref is passed into the dbd_db_login6() function via
    Driver.xst so attributes can be handled at connect time.

    All mysql connect-time options should be settable via connect-time
    attributes (can make them read-only after that by deleting them
    from the attribute hash and having STORE croak on them).
    Switching over to dbd_db_login6 is already on the list :) But I'd like to
    get this version up. Right now, I just need to test the change to
    found_rows, and then I will spin another beta, and if that looks good,
    upload it to CPAN.
    Oh and BTW, this is already
    configurable on the connect string 'mysql_found_rows=1'.
    Sure, but the problem is that editing the DSN in generic code is tricky.
    (Class::DBI is an example).
    Tell me about it!


    Rudy
  • Tim Bunce at Jun 9, 2003 at 4:21 pm
    Okay. Thanks.

    Tim.
    On Mon, Jun 09, 2003 at 10:56:50AM -0400, Rudy Lippan wrote:
    On Mon, 9 Jun 2003, Tim Bunce wrote:
    On Mon, Jun 09, 2003 at 01:11:18AM -0400, Rudy Lippan wrote:
    And now I remember why I did not create an attribute for it.
    CLINET_FOUND_ROWS is a connect-time option, so it does no good to create a
    dbh attribute to change the value.
    Ah, but you can now do it via an attribute...

    The attribute ref is passed into the dbd_db_login6() function via
    Driver.xst so attributes can be handled at connect time.

    All mysql connect-time options should be settable via connect-time
    attributes (can make them read-only after that by deleting them
    from the attribute hash and having STORE croak on them).
    Switching over to dbd_db_login6 is already on the list :) But I'd like to
    get this version up. Right now, I just need to test the change to
    found_rows, and then I will spin another beta, and if that looks good,
    upload it to CPAN.
    Oh and BTW, this is already
    configurable on the connect string 'mysql_found_rows=1'.
    Sure, but the problem is that editing the DSN in generic code is tricky.
    (Class::DBI is an example).
    Tell me about it!


    Rudy
  • Rudy Lippan at Jun 11, 2003 at 2:27 am
    Tim,

    DBD::mysql is packaged as a bundle. When I do a release, will I also need
    to bump the version number on the bundle?

    TIA,

    Rudy
  • Tim Bunce at Jun 11, 2003 at 11:24 am

    On Tue, Jun 10, 2003 at 10:29:16PM -0400, Rudy Lippan wrote:

    Tim,

    DBD::mysql is packaged as a bundle. When I do a release, will I also need
    to bump the version number on the bundle?
    Yes, but the Makefile.PL says

    'VERSION_FROM' => 'lib/DBD/mysql.pm'

    so it'll be looked after for you :)

    Tim.

    p.s. I'd like to see mysql.pod merged into mysql.pm. Just add it after a
    __END__ token then perl won't even bother reading it when it loads the driver.
  • Rudy Lippan at Jun 16, 2003 at 6:25 am

    On Wed, 11 Jun 2003, Tim Bunce wrote:

    Date: Wed, 11 Jun 2003 12:23:54 +0100
    DBD::mysql is packaged as a bundle. When I do a release, will I also need
    to bump the version number on the bundle?
    Yes, but the Makefile.PL says

    'VERSION_FROM' => 'lib/DBD/mysql.pm'

    so it'll be looked after for you :)
    On cpan there are two "Bundle::DBD::mysql's" one is version 2.0419 and one
    is 2.0416. 2.0419 has Msql-Mysql-modules-1.2219 and 2.0416 has
    DBD-mysql-2.1027 and 1.2219 is not in the Changelog. So I am a lttile
    confused as to why the current version has a Bundle version that is < the
    previous version?

    p.s. I'd like to see mysql.pod merged into mysql.pm. Just add it after a
    __END__ token then perl won't even bother reading it when it loads the driver.
    Done.

    Rudy.
  • Tim Bunce at Jun 16, 2003 at 9:33 am

    On Mon, Jun 16, 2003 at 02:27:31AM -0400, Rudy Lippan wrote:
    On Wed, 11 Jun 2003, Tim Bunce wrote:

    Date: Wed, 11 Jun 2003 12:23:54 +0100
    DBD::mysql is packaged as a bundle. When I do a release, will I also need
    to bump the version number on the bundle?
    Yes, but the Makefile.PL says

    'VERSION_FROM' => 'lib/DBD/mysql.pm'

    so it'll be looked after for you :)
    On cpan there are two "Bundle::DBD::mysql's" one is version 2.0419 and one
    is 2.0416.
    Umm, http://search.cpan.org/search?query=bundle%3A%3ADBD%3A%3Amysql&mode=all
    lists two when searching for "all":

    Bundle::DBD::mysql
    A bundle to install Perl drivers for mSQL or MySQL
    Msql-Mysql-modules-1.2219 - 30 Oct 2001 - Jochen Wiedmann

    Bundle::DBD::mysql
    A bundle to install Perl drivers for mSQL or MySQL
    DBD-mysql-2.1027 - 31 May 2003 - Jochen Wiedmann

    but only one when searching for "modules". Odd.

    2.0419 has Msql-Mysql-modules-1.2219 and 2.0416 has
    DBD-mysql-2.1027 and 1.2219 is not in the Changelog. So I am a lttile
    confused as to why the current version has a Bundle version that is < the
    previous version?
    Personally I think using four digits for subversion is over the top.
    I'd suggest you not worry too much about past confusions and bump
    the version on everything to 2.9001 for now.

    Once the prepared statement code gets integrated then go to a nice
    simple 3.00 :)
    p.s. I'd like to see mysql.pod merged into mysql.pm. Just add it after a
    __END__ token then perl won't even bother reading it when it loads the driver.
    Done.
    Thanks.

    Tim.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbi-dev @
categoriesperl
postedMay 29, '03 at 8:26a
activeJun 16, '03 at 9:33a
posts14
users2
websitedbi.perl.org

2 users in discussion

Rudy Lippan: 7 posts Tim Bunce: 7 posts

People

Translate

site design / logo © 2019 Grokbase