DBD::mysql 4.019 Released

2011-05-09 Thread Patrick Galbraith
Dear Perl and MySQL enthusiasts,

I’m pleased to announce the release of DBD::mysql 4.019. I’m
especially pleased because there are some new enhancements and
features that have been provided by contributions from the community:

* Asynchronous support, added by Rob Hoelz. This is a new feature to
DBD::mysql that takes advantage of libmysql’s asynchronous functions
(see Jan’s article from 2008
http://jan.kneschke.de/2008/9/9/async-mysql-queries-with-c-api/) .
From the DBD::mysql documentation:

You can make a single asynchronous query per MySQL connection; this
allows you to submit a long-running query to the server and have an
event loop
inform you when it’s ready. An asynchronous query is started by either
setting the ‘async’ attribute to a true value in the DBI do() method,
or in the DBI prepare() method. Statements created with async set to
true in prepare always run their queries asynchronously when DBI
execute() is called. The driver also offers three additional methods:
mysql_async_result, mysql_async_ready(), and mysql_fd.
mysql_async_result() returns what do or execute would have; that is,
the number of rows affected. mysql_async_ready() returns true if
mysql_async_result() will not block, and zero otherwise. They both
return undef if that handle is not currently running an asynchronous
query. mysql_fd returns the file descriptor number for the MySQL
connection; you can use this in an event loop.

  use feature 'say';
  $dbh-do('SELECT SLEEP(10)', { async = 1 });
  until($dbh-mysql_async_ready) {
say 'not ready yet!';
sleep 1;
  }
  my $rows = $dbh-mysql_async_result;

* Enable environment variables for installation options from Amiri
Barksdale. This is a feature that makes installation easier. For
instance, you can set:

export DBD_MYSQL_TESTDB=test
export DBD_MYSQL_TESTHOST=localhost
export DBD_MYSQL_TESTPASSWORD=s3kr1+

And then when you build and test DBD::mysql, the installation process
will automatically pick these values up. There are many more
environment variables documented on the DBD::mysql POD

* Other various cleanups, fix from Pedro Melo which fixed code from
4.018 that broke in newer versions of Perl
* Cleanup of some warnings that persnickety compilers complained about

It’s great moving this project along, and I appreciate the patches and
suggestions from the community!

The code can be found at:

http://search.cpan.org/~capttofu/DBD-mysql-4.019/lib/DBD/mysql.pm

Or

git clone https://github.com/CaptTofu/DBD-mysql


Decoding data from the database in DBD

2011-05-09 Thread Martin J. Evans
I've recently had an rt posted 
(http://rt.cpan.org/Public/Bug/Display.html?id=67994) after a discussion 
on stackoverflow 
(http://stackoverflow.com/questions/5912082/automatic-character-encoding-handling-in-perl-dbi-dbdodbc).


In this case the Perl script is binding the columns but the data 
returned is windows-1252 and the user is having to manually 
Encode::decode all bound columns. DBD::ODBC already had a odbc_utf8_on 
flag 
(http://search.cpan.org/~mjevans/DBD-ODBC-1.29/ODBC.pm#odbc_utf8_on) for 
a derivative of Postgres which returns bound data UTF-8 encoded but in 
that case I can just call sv_utf8_decode (in the XS) and it is converted 
in place. Initially I thought I could combine odbc_utf8_on into a new 
flag saying my data is returned as xxx and just call Encode::decode with 
xxx (then eventually I could drop odbc_utf8_on).


However, Encode::decode converts a scalar returning a new scalar (not 
converted in place). Just wondered if anyone else has had to do this. 
I've never called a module method from XS so I got some pointers at 
http://www.perlmonks.org/?node_id=903729 which are useful but I'm still 
wondering how anyone else has solved this before I try and implement 
something.


Thanks

Martin


Re: DBD::mysql 4.019 Released

2011-05-09 Thread Tim Bunce
On Mon, May 09, 2011 at 02:24:21PM -0400, Patrick Galbraith wrote:
 
 You can make a single asynchronous query per MySQL connection; this
 allows you to submit a long-running query to the server and have an
 event loop inform you when it’s ready.

That's great, but...

 An asynchronous query is started by either
 setting the ‘async’ attribute to a true value

... that should be 'mysql_async'. I.e., the name of the driver-private
attribute should include the drivers prefix.

Please add mysql_async and deprecate async in the next release.

Tim.


Re: Decoding data from the database in DBD

2011-05-09 Thread Tim Bunce
On Mon, May 09, 2011 at 07:42:53PM +0100, Martin J. Evans wrote:
 I've recently had an rt posted
 (http://rt.cpan.org/Public/Bug/Display.html?id=67994) after a
 discussion on stackoverflow 
 (http://stackoverflow.com/questions/5912082/automatic-character-encoding-handling-in-perl-dbi-dbdodbc).
 
 In this case the Perl script is binding the columns but the data
 returned is windows-1252 and the user is having to manually
 Encode::decode all bound columns. DBD::ODBC already had a
 odbc_utf8_on flag
 (http://search.cpan.org/~mjevans/DBD-ODBC-1.29/ODBC.pm#odbc_utf8_on)
 for a derivative of Postgres which returns bound data UTF-8 encoded
 but in that case I can just call sv_utf8_decode (in the XS) and it
 is converted in place. Initially I thought I could combine
 odbc_utf8_on into a new flag saying my data is returned as xxx and
 just call Encode::decode with xxx (then eventually I could drop
 odbc_utf8_on).

I'd be wary of going down this path.  I sense pain just beyond the horizon.
A twisty-turny maze of sharp edge cases and unforseen issues.

For a start: What about the charset of bind values?  What about the
charset of SQL literals?

Can't the database connection/session settings be altered to assume utf8
at the client end and have the server or client libs automatically
convert for you? If so, that's a good way to go.

Tim.