DBD::mysql 4.027 released

2014-03-25 Thread Patrick Galbraith
Dear Perl community,

I’m pleased to announce the release of DBD::mysql 4.027. This release isn’t a 
huge release but has some nice fixes nonetheless. Particularly, some fixes that 
improve building and installing on OS X.

Per the change log:

2014-13-15 Patrick Galbraith, Michiel Beijen, DBI/DBD community (4.027)
* Added more OS X notes and fixed compiler warnings
* Skip tests if test database is not present-RT92330 (zefram 
* metacpan.org and search.cpan.org didn't display module POD, caused by fix for 
RT90101. Reported by Oleg, RT92350.

As before, thank you to Michael Beijen and the community for your help!

You can find the latest in github:

https://github.com/perl5-dbi/DBD-mysql

As well as CPAN:

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

Thank you for using DBD::mysql!

Patrick Galbraith

Re: DBI Mysql Driver Handle Mysteriously Changes!

2014-03-25 Thread Tim Bunce
Hello Duncan.

On Tue, Mar 25, 2014 at 04:42:56PM +1300, Duncan McEwan wrote:
> 
> First, a brief recap.  We have a web-based application that runs as a FosWiki 
> plugin under Apache/fcgid.

Could you post the fcgid configuration details for us?
https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html

> The database connection used by this application should be persistent
> due to the application calling DBI->connect_cached() on each invocation.

Persistent within a single backend process, yes.

> The new piece of information that I have discovered recently is that on a
> call to connect_cached() which *doesn't* return the cached database handle,
> the database driver handle reference passed into connect_cached() has changed.
> Since the dbh cache is obtained from "$drh->{CachedKids} ||= {}" I can now
> understand why the cached handled is not found!
> 
> What I can't understand is why the driver handle passed into connect_cached()
> has changed!

Neither can I.

> I've got 1000's of lines of debugging showing this happening.  Some of it
> is my own, inserted as print statements or cluck calls directly into DBI.pm
> and some of it the standard DBI debugging set to level 9.  There is way too
> much to include in this message, but I've included some small extracts below
> to illustrate what I am seeing.

What you've included doesn't show the drh changing.

I suggest you focus on that. Specifically the code path taken by the
request that notices that the drh has changed, _and_ the code path taken
by the _previous_ request _in the same process_.

> One thing I did just notice is that our application calls connect_cached()
> in the way shown in the DBI pod - that is:
> 
>   my $dbh = DBI->connect_cached(...)
> 
> I don't know enough about perl internals to know exactly what this does.
> But I did wonder if something like the following might be better given the
> persistent nature of our application provided by fcgid.
> 
>   my $dbi = new DBI;
>   my $dbh = $dbi->connect_cached(...)

No. Using new DBI (or DBI->new) isn't a valid way to use the DBI.
Just DBI->connect_cached is fine.

Tim.