Re: Bugtracker DBD::mysql

[Patrick Galbraith]

I of course will gladly work with you on this.


On 11/14/2017 04:56 AM, Michiel Beijen wrote:

Hi Pali,

On Mon, Nov 13, 2017 at 6:18 PM,   wrote:

And I would suggest to disable issue tracker on github as primary bug
tracker (according to DBD::mysql documentation) is on RT and also
probably all problems are reported there. The worst thing which can be
is to have two independent bug trackers, which is current situation.

You're right, it would be helpful and desirable to have only one bug tracker!

I've tried to migrate the existing RT tickets to Github before, but
that did not work correctly because DBD::mysql uses a Github
organization and the script I used at the time did not accept this.
I'll put it higher on my to-do list again and look into getting that
done.

--
Michiel

Re: DBD::mysql path forward

[Patrick Galbraith]

Pali,

I totally understand - timing timing - I started a new job and found out 
I had to prepare to talk about MySQL/Kubernetes at kubecon, so I 
apologize, and didn't plan it that way. Let me re-review those emails 
and give a decision, of course, your decision as well.


As far as maintainer, you are an equal, and if you need to be seen as a 
decision maker and we work by consensus with you having equal decision. 
I'm glad with that as well because I do appreciate all of your 
contributions.  I'm sorry for what you mentioned in the past though it 
was more of a reaction to deal with "customers" having issues and 
working panic mode, not a slight to your efforts. What would you prefer?


So, what would be ideal for us to move forward is to get the utf8 fixes 
into the master branch, then work in the subsequent fixes that came 
after June, do a pre-release, a period of time for people to test/try 
out, then release. What sort of git gymnastics does this require?  What 
do you think?


I think the key here to have a single driver that supports both Maria 
and MySQL both and not have splintering, and more than anything, provide 
stability as well as new features for users.


Regards,

Patrick



On 11/05/2017 04:24 AM, p...@cpan.org wrote:

Hi!

Have you got replies from people who you informed/asked about that
problems?

What is needed from you is to decide how to handle problems with
encoding and other bugs reported for DBD-mysql project [1].

I sent in previous email some proposed solutions and I'm just waiting
which would be chosen... I just do not like "silence" and no step
forward. Just to note that Dan Book asked month ago for next steps.

Also, I'm not very happy to see being co-maintainer of DBD::mysql,
specially in this time when nothing happened for 5 months, plus some
people opposed to me and wanted to revert bug fixes and contributions by
me...

[1] -https://rt.cpan.org/Public/Dist/Display.html?Name=DBD-mysql  


On Friday 03 November 2017 16:17:09 Patrick M. Galbraith wrote:

Pali,

Sorry, I wanted to give it time for people, plus have been very busy.
I'm ready, just let me know when we can get code merged back in--
what do you need me to do? I will need help with this.

Regards,

Patrick

On 11/2/17 1:43 PM,p...@cpan.org  wrote:

On Tuesday 12 September 2017 11:40:31 Patrick M. Galbraith wrote:

Hi all,

After talking to Pali and looking at how other drivers have
handled the issue, the best way forward will be to deal with
solving the UTF-8 issue correctly as was attempted in May. This
will be a problem for some, but only due to having to been
accustomed to a work-around that relies on a intermittent and
buggy implementation. The plan is to give ample time to let
people prepare and comment as well as give them a chance to try
the changes and adjust prior to stable release. I'm going to look
through the mailing list and find particularly those who had
problems back in May and June when we tried this before and work
with them in advance of the change.

DBD::mysql should be on par with all the other DBD drivers and
allow transparent usage regardless of backing RDBMS, and this
really is the only way. It will also allow for other fixes to
proceed and the driver to continue improving and supporting all
versions and enhancements of MySQL and MariaDB.

Please do give us your thoughts on this as we want to be as
helpful and transparent as possible.

Thank you!

Patrick

Hi! Nearly another two months passed and there is no progress in
unblocking development.

Currently more people started reporting problems that new versions
of both MySQL and MariaDB cannot be used for building DBD::mysql.

As I stated two months ago, we are thinking about forking
DBD::mysql as inability to build DBD::mysql with new version of
MySQL or MariaDB is a real problem which needs to be fixed ASAP --
and not waiting another 6 months.

Re: DBD::mysql path forward

[Patrick Galbraith]

Dan,

I think get the original work Pali did (I need to get the master-new he 
references below in) and also I need to figure out what it will 
inevitably mean for distribution packages. And test, and test. I need to 
also find the emails of people who had a problem last time and have a 
plan to get people able to adopt and use the driver changes and give 
them all the info they need to modify their code to work with the proper 
driver.


regards,

Patrick


On 10/04/2017 04:49 PM, Dan Book wrote:

How can we proceed from here?
-Dan

On Mon, Sep 18, 2017 at 1:17 PM, Patrick M. Galbraith > wrote:


Pali,

Great! Now we can start moving forward.

Sorry if my responses have been intermittent - first week at new job.

Regards,

Patrick

On 9/16/17 4:35 AM, p...@cpan.org  wrote:

I prepared branch master-new, which is based on current DBD-mysql master
branch and revert state to pre-4.043 version, including all changes done
after 4.043 release to master branch. I have this master-new branch in
my fork. If you want you can use it...

https://github.com/pali/DBD-mysql/tree/master-new

DBD::mysql 4.039 released

[Patrick Galbraith]

Dear Perl community,

I’m pleased to announce the release of DBD::Mysql 4.039. This release contains 
a fix to a vulnerability that was found and now fixed per CVE-2016-1249. A 
description from the advisory reads:

A vulnerability was discovered that can lead to an out-of-bounds read
when using server side prepared statements with an unaligned number of
placeholders in WHERE condition and output fields in SELECT expression.

Versions known to be affected — 2.9004 and later (2005 and later)
Versions known to be not affected — 2.9003 and earlier (before 2005)
Version containing Fix — 4.039 and later (current)

Thanks to Pali Rohár for discovering and fixing this vulnerability!

The mirrors on CPAN should now be up to date and the release found at 
http://search.cpan.org/~capttofu/DBD-mysql-4.039/lib/DBD/mysql.pm 


The source code available at https://github.com/perl5-dbi/DBD-mysql

Regards,

Patrick and Michiel




signature.asc
Description: Message signed with OpenPGP using GPGMail

DBD::mysql release 4.031 released

[Patrick Galbraith]

Dear Perl and MySQL community,

We're pleased to announce the release of DBD::mysql 4.031!

The changes, per ChangeLog:

2015-03-05 Patrick Galbraith, Michiel Beijen, DBI/DBD community (4.031)
* Added LICENSE
* Reworked installation documentation in POD.
* Allow use of bracketed IPv6 addresses in connection string (RT70640),
   fix by Tim Mullin @ cPanel).
* Locate mysql_config in path on MSWin32 (RT94838, reported by CHORNY).
* Environment variable DBD_MYSQL_CONFIG actually works now.
* Makefile.PL now correcly handles MariaDB's mysql_config.
* Correct attribution to David Dick #86030: PATCH: adding statistics_info 
support
* Test suite can now be run in parallel. Fixes RT98994 reported by DOHERTY.
* Fixes for MySQL 5.6+ and for prepared statement handling (stevenh on github).
* Fix for RT100792, New test t/05dbcreate.t fails if user has no permissions. 
* Fix for bit test (RT68374, bjd...@cpan.org) CaptTofu added 40bit.t to test.

If there are no regressions reported in this release.

Also thanks to anyone who has contributed to this project. It’s our goal to 
always make sure to make use of so many great bug fixes and features that users 
in the community provide. 

In particular, I would like to thank Michiel Beijan, who has really prompted 
(and prodded!) me to help get this release.

Congratulations to Michiel as he is now co-maintainer for DBD::mysql!

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

DBD::mysql test release 4.030_01

[Patrick Galbraith]

Dear Perl and MySQL community,

I’m pleased to announce the release of DBD::mysql 4.030_01. This is a test 
release, meaning that we are on our way to a full-blown release. There are some 
great features in this release particularly to do with prepared statement 
handling on MySQL 5.6 as well as other features:


* Correct attribution to David Dick #86030: PATCH: adding statistics_info 
support
* Test suite can now be run in parallel. Fixes RT98994 reported by DOHERTY.
* Fixes for MySQL 5.6+ and for prepared statement handling (stevenh on github).
* Fix for RT100792, New test t/05dbcreate.t fails if user has no permissions. 
* Fix for bit test (RT68374, bjd...@cpan.org) CaptTofu added 40bit.t to test.

I want for first thank Michiel Beijen who was a catalyst for this release 
including reviewing bugs and ensuring fixes made it in, testing, verifying on 
Windows that all was well, as well as noticing David Dick didn’t receive 
correct attribution in a prior fix. I’m very grateful to be working with him!

Also thanks to anyone who has contributed to this project. It’s my goal to 
always make sure to make use of so many great bug fixes and features that users 
in the community provide.

Regards,

Patrick

CPAN:

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

Github:

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

DBD::mysql 4.029 released

[Patrick Galbraith]

I'm pleased to announce the release of DBD::mysql 4.029

From the changelog:

* Added fix to tests to create test database if not exists (contstant
failure on Travis) (CaptTofu)
* Support the fraction of (Oracle) MySQL Fabric that is supported by the
most recent Connector/C (Steffen Mueller smuelleratcpandotorg
* Statistics Info Milan ¿orm sormatis4udotcz for work on
statistics_info
* Fix for RT 97625, use after free(), Reini Urban rurbanatcpandotorg
and Giovanni Bechis giovanniatbigiodotsnbdotit


Thanks to all who contributed!

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

Code:

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

Patrick CaptTofu Galbraith

DBD::mysql 4.028 released

[Patrick Galbraith]

Dear Pert and MySQL community,

I”m pleased to announce the release of DBD::mysql 4.028. This release includes 
several fixes, per change log:

 * Fixed bug in mysql.xs where dbh was being used as error code
* RT #97570: fix wrong salloc free in mysql_st_internal_execute - (Reini Urban, 
cPanel)
* Fix RT #97625 use-after-free in mysql_dr_error, and #86153 - (Reini Urban, 
cPanel)
* find mysql.h for MariaDB on Win32 (Graham Ollis)
* Update mysql.pm to work with ipv6 and ipv4 addresses (katyavoid)

I want to thank Reini Urban, Graham Ollis, and Katyavoid for their pull 
requests and contributions to DBD::mysql!

Please feel free to visit:

 http://search.cpan.org/~capttofu/DBD-mysql-4.028/

And as always:

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

Regards,

Patrick Galbraith


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: DBD::mysql 4.028 released

[Patrick Galbraith]

So sorry, I need to wear reading glasses before sending!

Perl Community!

On Aug 2, 2014, at 11:15 PM, Patrick Galbraith p...@patg.net wrote:

 Dear Pert and MySQL community,
 
 I”m pleased to announce the release of DBD::mysql 4.028. This release 
 includes several fixes, per change log:
 
  * Fixed bug in mysql.xs where dbh was being used as error code
 * RT #97570: fix wrong salloc free in mysql_st_internal_execute - (Reini 
 Urban, cPanel)
 * Fix RT #97625 use-after-free in mysql_dr_error, and #86153 - (Reini Urban, 
 cPanel)
 * find mysql.h for MariaDB on Win32 (Graham Ollis)
 * Update mysql.pm to work with ipv6 and ipv4 addresses (katyavoid)
 
 I want to thank Reini Urban, Graham Ollis, and Katyavoid for their pull 
 requests and contributions to DBD::mysql!
 
 Please feel free to visit:
 
  http://search.cpan.org/~capttofu/DBD-mysql-4.028/
 
 And as always:
 
 https://github.com/perl5-dbi/DBD-mysql.git
 
 Regards,
 
 Patrick Galbraith



signature.asc
Description: Message signed with OpenPGP using GPGMail

DBD::mysql 4.027 released

[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 zefram at fysh 
dot org
* 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

Fwd: DBD::mysql 4.024 Released

[Patrick Galbraith]

Hi all,

As Michiel announced, I wanted to share what I had sent on dbi-announce but
not dbi-users. Particularly the help that Michiel gave for this release!

-- Forwarded message --
From: Patrick Galbraith p...@patg.net
Date: Wed, Sep 18, 2013 at 1:33 AM
Subject: DBD::mysql 4.024 Released
To: dbi-annou...@perl.org dbi-annou...@perl.org


Dear community,

I'm quite pleased to announce the release of DBD::mysql 4.024. This release
has been made possible by the most-appreciated help of Michiel Beijen and
others who helped me out to get some work done and the project moving. Also
a great thanks to Rudy Lippan for reminding me that people were interested
in helping!

The fixes in this release:

* Fix memory leak if mysql_server_prepare is enabled - RT76462 - Masahiro
Chiba
* Small dist improvements:  Michiel Beijen michiel.bei...@otrs.com
* Undefined $DBI::errstr on execute fail on Windows: Michiel Beijen 
michiel.bei...@otrs.com
* Better diagnostics for 80procs.t Fixes RT#71199: Alexandr Ciornii 
alexcho...@gmail.com
* Fix #64013: INSTALL.pod is shown with 'man install': Juergen Weigert 
j...@suse.com
* Added 'testport' to keys in Makefile.PL Fixes RT#83492: Michiel Beijen 
michiel.bei...@otrs.com
* Fixed test 70takeimp warning. Michiel Beijen michiel.bei...@otrs.com
* Made test t/87async.t not stop on Win32. Michiel Beijen 
michiel.bei...@otrs.com
* Update github location.  Update support information. Michiel Beijen 
michiel.bei...@otrs.com
* POD Fixes  Patch from RT77043 by Gunnar Wolf, Debian Perl Group. Michiel
Beijen michiel.bei...@otrs.com

I hope that I've given credit to everyone, and if I've missed any one, I
want you to know that we greatly appreciated your help!

The distribution can be found at:

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

Also, important to note is that the DBD::mysql git repo is now at:

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

Again, thank you and particularly thank thank you Michiel!

Regards,

Patrick Galbraith

DBD::mysql 4.022 released

[Patrick Galbraith]

Greetings,

I am pleased to announce the release of DBD::mysql 4.022.

This release contains several fixes from the community, as outlined in the 
change log:

* Fixes for Win32 from Rom Hoelz (https://github.com/hoelzro) 
* Pulling back in work for 4.021 that didn't get pushed and much other work 
from Chip Salzenberg (https://github.com/chipdude)
* Column info order fix from Tokuhiro Matsuno (https://github.com/tokuhirom)
* Fix AutoCommit comparison logic to avoid spurious commands to mysql from 
Matthew Horsfall (https://github.com/wolfsage)
* server_preapre can't bind placeholder on comment. from Misahiro Chiba 
(https://github.com/nihen)
* server_prepare; data is null, allocate big memory bug. from Misahiro Chiba 
(https://github.com/nihen)

Also thank you to Kris Davey for point out to me this link for installing 
DBD::mysql on OS X:

https://discussions.apple.com/thread/3932531?start=0tstart=0fb_source=message

I have updated the README file to point people in this direction.

Thank you to everyone for using this and especially those who submitted pull 
requests on github!

The CPAN link is:

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

And Github, for latest code and pull requests:

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

Regards,

Patrick

DBD::mysql 4.021 released

[Patrick Galbraith]

Hi all,

I am pleased to announce the release of DBD::mysql 4.021!

This release includes the following fixes per change log:

2011-08-15 Patrick Galbraith (work of others) patg at patg dot net (4.021)
* Fix to enable PERL_NO_GET_CONTEXT to speed up DBD performance on thread Perls 
(Dave Mitchell davem at iabyn dot com) Thank you!
* Fix to is_prefix not being exported by mysql Aran Deltax bluefeet at gmail 
dot com Thank you!
* Eliminate DBIS usage Dagfinn Ilmari Mannsåker ilmari at ilmari dot org 
Thank you!
* Enhanced / Fixed server side prepared statement checks (Steven Hartland) 
Thank you!
* Fix missprint in doc of DBD::mysql of mysql_bind_type_guessing (Perlover 
http://blog.perloever.com) Thank you!
* Misprint in lib/DBD/mysql.pm (Perlover) Thank you!

Thank you for all the great contributions to DBD::mysql, greatly appreciated!

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

And

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

Regards,

Patrick

DBD::mysql 4.020 released

[Patrick Galbraith]

Dear Perl community,

I'm pleased to announce the release of DBD::mysql, the MySQL Perl
client, 4.020. The release has several great fixes provided by the
community, and in particular from Masahiro Chiba, who fixed several
issues pertaining to prepared statement support as well as UTF8
support, something that I myself have had a difficult time fixing and
testing.

From the Change log:

2011-08-15 Patrick Galbraith patg at patg dot net (4.020)
* Numerous (!! Thank you!!) fixes for prepared statements: Masahiro
Chiba nihen at megabbs
dot com
- Chop blanks fixed
- UTF8 improvements
- fixed memory allocation for BLOBs
- auto-reconnect
* Fix in leak test, which failed sometime due to first assignment
$prev_size over
paging (Masahiro Chiba)
* Catalog test allows use of schemas other than 'test' (Masahiro Chiba)
* Documentation fix for auto_reconnect (Karen Etheridge ether at cpan dot
org)
* Win32 and general installation fixes (Alexandr Ciornii, http://chorny.net)

I want to thank Masahiro, Karen and Alexandr for their contributions,
which made this release possible. I want to again thank everyone who
submits bugs as well as simply using this driver!

The release can be found at:

http://search.cpan.org/~capttofu/DBD-mysql-4.020/

Kind regards,

Patrick Galbraith

DBD::mysql 4.019 Released

[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

DBD::drizzle .301 released

[Patrick Galbraith]

Hi all,

I have just uploaded to CPAN DBD::drizzle .301. This includes a fix from 
Eric Day to fix to NULL handling as well as some rewriting of 
column_info, which used to use DESCRIBE and SHOW commands, but since the 
direction of Drizzle encourages use of both information_schema and 
data_dictionary, I've utilized these instead for catalogue information.


Once the mirrors update, you should be able to use CPAN for obtaining 
DBD::drizzle, or you can obtain it from Launchpad:


lp:dbd-drizzle

Thanks for reminding me to get this out, dear Perl and Drizzle enthusiasts!

Your friend,

Patrick CaptTofu Galbraith

Re: Strange Error

[Patrick Galbraith]

Jerry,

Hi there - I'm the maintainer of DBD::mysql

The verbiage going to your log looks like what you would see if you set 
the DBI trace level to 2 or greater. I've double-checked my code and any 
debug I print is indeed only occurring in a block where if trace is set 
to 2 or greater it would show up.


I wonder if CGI::Application might set trace? Or what about any sort of 
Apache/mod_perl startup scripts that might set it - have you checked those?


--Patrick

Jerry Kaidor wrote:

Hello,

   My name is Jerry Kaidor.  I am seeing some cryptic errors in a web
application that I'm writing.  Driving me nuts. My code runs under
CGI::Application, and uses DBI with the mysql driver.  Here is the
error message, which appears in /var/log/httpd/error_log:

- snip 

[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] SV =
RV(0x8c6212c) at 0x8c62120
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]   REFCNT = 1
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]   FLAGS =
(ROK,READONLY)
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]   RV = 0x8c61ef0
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] SV =
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] PVHV(0x8c57b84)
at 0x8c61ef0
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]   REFCNT = 1
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]   FLAGS =
(OBJECT,OOK,SHAREKEYS)
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]   STASH = 0x8700430
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] \tDBI::db
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]   ARRAY = 0x8c66878
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]   KEYS = 0
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]   FILL = 0
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]   MAX = 7
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]   RITER = -1
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]
[Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6]   EITER = 0x0

 endsnip 

   The Linux system is based on Slackware 13.0.  I have upgraded to the
latest DBI and DBD::mysql via CPAN.  The Linux kernel is 2.6.29.6-smp. 
Perl is v5.10.0 built for i486-linux-thread-multi.  The mysql server

is 5.0.84.  The webserver is Apache 2.2.13.

   I have done a fair amount of googling on this, no joy, except that the
error messages seem to be about some kind of Perl internals distress. 
I also asked the CGI::Application mailing list - they know nothing. 
One person suspected the DBD driver because it uses C code interfaced

to Perl via XS.

   Anybody have a clue?  BTW, the application seems to work fine.   I'm
just seeing this error in the httpd error log.

   Thanks in advance,

   - Jerry Kaidor ( je...@tr2.com )



  

DBD::mysql 4.015 Released

[Patrick Galbraith]

I'm glad to let everyone out in Perl Land know that DBD::mysql 4.015 is 
released. Per the changelog:


* BUG #56664 fixed t/40blobs.t skip_all logic (W. Phillip Moore)
* BUG #57253 Fixed iteration past end of string (crash). (Chris Butler)
* Added a new parameter for old behavior- 
mysql_bind_comment_placeholders which
 will make it possible to have placeholders bound within comments for 
those who really

 want that behavior.
* Fixed bind_type_guessing - always on now. Numbers will not be 
automatically quoted as they are now.


You can get the latest release at:

http://search.cpan.org/~capttofu/DBD-mysql-4.015/

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.015.tar.gz
size: 132029 bytes
 md5: 4d80bb5000b97bbfbe156140b9560c20

Also, the latest source:

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

Thanks for using DBD::mysql and reporting bugs!

--Patrick 'CaptTofu' Galbraith

DBD::mysql 4.014 released

[Patrick Galbraith]

It's been an extremely busy year thus far with all the great work we're 
doing at NorthScale as well as the release of CaptTofu 2.0 (My son 
Kiran!). With the new UI on rt.cpan.org, in my spare time, I went 
through and closed some bugs, hence a new release of DBD::mysql, 4.014. 
In this release:


* BUG 30033 Fixed handling of comments to allow comments that contain 
characters

 that might otherwise cause placeholder detection to not work properly
* BUG 53844, Fix for memory leak in stats. (Gregory Burmistrov)
* BUG 49719, Fix for handling of NULLs in prepared statements (Gert Pache)
* BUG 55627, Fix for testing failure due to strict mode (Yves)
* BUG 51784, Fix for mysqladmin on Windows in Makefile (Zeeshan Muhammad)
* BUG 41630, Typo in Makefile

There are other bugs in rt.cpan.org, hence a pending release in the next 
week or two. I like an empty bug list!
Thank you to Gregory Burmistrov, Gert Pache, Yves, Zeeshan Muhammad for 
your patches!


You can find the code at:

http://search.cpan.org/~capttofu/DBD-mysql-4.014/

The file:

 file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.014.tar.gz
 size: 131270 bytes
  md5: 74f118a4984e6a49f8ece28e68caf543


Also, I have moved the source repository from Subversion to Git (Github)

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

Why Github? I've really grown to like Git once my brain wrapped around 
it. No slight to any other system. I have DBD::drizzle hosted at 
Launchpad. At least now, I have to only concentrate on remembering how 
to use two revision control systems!

DBD:drizzle 0.200 Released

[Patrick Galbraith]

I'm pleased to announce the release of DBD::drizzle 0.200. This release 
fixes several issues, per Changelog:


* Fixed broken tests
* Fixed bind_type_guessing to work as it does in DBD::mysql
* Added missing insert_id database handle attribute fetching
* Added several tests that were missing that exist in DBD::mysql
* Removed extra cruft from lib.pl
* Fixed hash-key retrieval for connection options
* Fixed double-free of imp_dbh-result in dbd_st_destroy

Also worth mentioning is that I've back-ported several fixes that have 
been made to DBD::mysql.


I would like to thank everyone who has sent bug reports, patches, and is 
using this new driver!



The files:

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-drizzle-0.200.tar.gz
size: 80829 bytes
md5: 9394df460d6d6c70c96cc500dd5a778f

Also:

http://search.cpan.org/~capttofu/DBD-drizzle-0.200/lib/DBD/drizzle.pm

regards, Patrick Galbraith aka CaptTofu

DBD::drizzle 0.100 Released!

[Patrick Galbraith]

Hi community!

I'm incredibly elated to announce the release of DBD::drizzle 0.100. 
What is different about this release? It uses Eric Day's new client 
library, libdrizzle! This means we could eventually package the client 
with DBD::drizzle, eliminating the issues I have with DBD::mysql where 
code doesn't compile because of trying to compile DBD::drizzle against a 
MySQL client binary produced on a different machine with a different 
compiler and compile flags.


I want to thank Clint Byrum - immense thanks- for his work, which the 
majority of, made this possible. He and I spent the last several days 
together at the users conference going over the code, getting it to 
work. We achieved together more in hours time what would have taken days 
or even weeks. I'm also glad to have gotten to know Clint-- it's great 
to make new friends!


The next step is that we'll probably write this from scratch at some 
point. Right now, this is a retro-fit of DBD::mysql, which works just 
fine. However, we would like write a low-level 1:1 Perl:C layer of 
libdrizzle which we would then make DBD::drizzle to take advantage of 
libdrizzle's various features-- especially asynchronous features-- that 
might not be easy to access within the framework of DBI. I particularly 
like the way Tim Bunce's Memcached::libmemcached works with Daisuke 
Maki's Cache::Memcached::libmemcached-- something of that idea I would 
like to do with DBD::drizzle.


So, go get the code!!! All tests pass!

http://search.cpan.org/dist/DBD-drizzle/

The files:

$CPAN/authors/id/C/CA/CAPTTOFU/DBD-drizzle-0.100.tar.gz
size: 82715 bytes
md5: fb80f344cabe248b18ea238ebf8d4da3

Credits and praise:

* Clint Byrum
* Eric Day

Re: DBD::oracle question about auto reconnecting

[Patrick Galbraith]

John Scoles wrote:

Not that I am aware of.

Is auto-reconnect  a specific MYSQL command of some sort or is a PERL 
base command or some sort?


Can you give me an example of how it is used?

cheers
John Scoles

Patrick Galbraith wrote:

Hi there,

Is there the equivalent of an auto-reconnect with DBD::Oracle as 
DBD::mysql has (appended in the connect DSN) ?


Thanks!

Patrick

John,

Hi! DBD::mysql uses mysql_auto_reconnect to connect back to MySQL if the 
connection drops


$dbh= DBI-connect('DBI:mysql:test:mysql_auto_reconnect=1', $foo, $fee)...;

or of course

$dbh-{mysql_auto_reconnect};

In the perl side of the driver:

if ($this  ($ENV{MOD_PERL} || $ENV{GATEWAY_INTERFACE})) {
   $this-{mysql_auto_reconnect} = 1;
   }

I had this off once with a release I did, and a lot of people were very 
unhappy ;)


So, whatever might give the functionality to reconnect automatically

I suppose it'd be the same as doing

unless ($dbh-ping) {
   $dbh=  connect ...
}

Thanks much,

Patrick

DBD::oracle question about auto reconnecting

[Patrick Galbraith]

Hi there,

Is there the equivalent of an auto-reconnect with DBD::Oracle as 
DBD::mysql has (appended in the connect DSN) ?


Thanks!

Patrick

DBD::mysql 4.010 Released

[Patrick Galbraith]

I'm pleased to announce the release of DBD::mysql 4.010. This release 
contains:


* Fix to dbd_bind_ph() for uninitialized value 'buffer_length'
thanks for bug report and patch from Askniel.com (thanks!)

These fixes are 4.009, which I didn't send out a release email for:

* Fix to re-enable TAKE_IMP_DATA_VERSION. Still have to ensure DBI 
version 1.607 or higher
* Fix to escaped single quotes throwing off bind param detection. Patch 
from Zhurs ([EMAIL PROTECTED]) Spasibo!


Thanks to Niel Katin, Zhurs, Daniel Frett, as well as anyone who filed 
bugs and uses the software!


The file:

 file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.010.tar.gz
 size: 125211 bytes
  md5: a63c9f73afef70b6c80d899424b003e9

CPAN:

http://search.cpan.org/~capttofu/DBD-mysql-4.010/

Enjoy!

DBD::mysql 4.008 Released

[Patrick Galbraith]

Dear Perl and MySQL Community,

I'm pleased to announce the release of DBD::mysql 4.008!

This release contains several fixes, particularly the issue where 
TAKE_IMP_DATA_VERSION being defined allowed code features to be compiled 
in that caused potential grief for anyone running DBI  1.60x 
(segfault). I've disabled this for the time being until I find a better 
solution.


I've also decided from now on, as soon as I get a patch, or if I fix 
something, even if it is a minute change, I'm rolling out a release. 
Release early and often, right!?


The changes in this release are:

* Multi statement patch (fixes multi statement issues), thanks to Chris 
Heath!

* Disabled TAKE_IMP_DATA_VERSION because segfault with DBI  1.607
* #29528: bind_param(..., SQL_FLOAT) ignores exponents - fixed, Thanks to
Tokuhiro Matsuno!
* Cleanups to make mysqlEmb work under Cygwin - Thanks to Chris Rodgers
http://rodgers.org.uk/ !
* Modified and disabled tests for MySQL version  4.1 for unsupported 
features


Thanks again to Chris Heath, Tokuhiro Matsuno, and Chris Rodgers for 
their patches as well as to everyone else who was kind enough to report 
bugs!


File info:

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.008.tar.gz
size: 125033 bytes
md5: 11c9aea0b5d04d13043461f4a0c1dfcb

The release can be found at:

http://search.cpan.org/~capttofu/DBD-mysql-4.008/

Subversion, for those who want the most up to date code:

http://svn.perl.org/modules/DBD-mysql/

Thank you for using DBD::mysql and MySQL!

--

Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

DBD::mysql 4.007 released

[Patrick Galbraith]

I'm pleased to announce the release of DBD::mysql 4.007. This release contains 
the changes:

* Took out mysql_server_init call where not needed
* Complete re-write of test suit to use Test::More - tons of cleanups!
* Makefile.PL changes to use current user in 'make test' if not defined

The biggest change in this release is a completely re-written test suite now 
using Test::More. This was something I wanted to do for at least two years. 
Using Test::More for the test suite makes it so much easier to add, manage and 
understand the various tests that come with the driver.

The file is:

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.007.tar.gz
size: 123516 bytes
md5: 67a4d921acda942aeb0e65a0023f2098

URL:
http://search.cpan.org/~capttofu/DBD-mysql-4.007

Thank you for using DBD::mysql!


--
Patrick Galbraith, Senior Programmer 
Grazr - Easy feed grazing and sharing
http://www.grazr.com 


Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

aborted connections wierdness...

[Patrick Galbraith]

Hi all,

I've configured many a server in my life, but have this odd issue lately:

080428 14:45:47 [Warning] Aborted connection 3185826 to db: '' user: 
'x' host: 'dbserverxxx' (Got an error reading communication packets)


This is pretty much stock mod_perl setup, even using Apache::DBI.

I still have two boxes giving me this problem, whereas I have been able 
to get rid of this message on my other servers by changing my usage of 
connect_cached to just connect (Apache::DBI should give me 
connection caching). Problem went away on those servers just by doing 
that, but remains on the other two, despite the switch.


What other settings, factors might contribute to this?

Thanks in advance to thoughts/opinions.

regards,

Patrick

--
Patrick Galbraith, Senior Programmer 
Grazr - Easy feed grazing and sharing
http://www.grazr.com 


Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

Re: aborted connections wierdness...

[Patrick Galbraith]

Rudolf Lippan wrote:


On Mon, 28 Apr 2008 14:51:24 -0400, Patrick Galbraith [EMAIL PROTECTED]
wrote:
 


Hi all,

I've configured many a server in my life, but have this odd issue lately:

080428 14:45:47 [Warning] Aborted connection 3185826 to db: '' user:
'x' host: 'dbserverxxx' (Got an error reading communication packets)

   



Have you tried doing a packet trace to see exactly what is going on at the
network level? 
 



Not yet - I haven't messed around with tcp dump much, but maybe now is 
the time to start. What would I be looking at?



-r


 




--
Patrick Galbraith, Senior Programmer 
Grazr - Easy feed grazing and sharing
http://www.grazr.com 


Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

Re: Silly Question

[Patrick Galbraith]

John Scoles wrote:


Who is the current maintainer of DBD::MySQL??


John,

I am.

regards,

Patrick

--
Patrick Galbraith, Senior Programmer 
Grazr - Easy feed grazing and sharing
http://www.grazr.com 


Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

DBD::mysql 4.006 Released

[Patrick Galbraith]

Dear DBD::mysql users and developers,

I'm pleased to announce the release of DBD::mysql 4.006. This release 
contains various fixes, per Changelog:


* Cleanups on OS X compile
* Fixes to syntax errors on AIX
* Removed test code that was leaving trace files around

The release file's info:

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.006.tar.gz
size: 129510 bytes
md5: 133ac08c22bb19194ad8b895e3204310

URL:

http://search.cpan.org/~capttofu/DBD-mysql-4.006/

Kind regards,

Patrick Galbraith

--
Patrick Galbraith, Senior Programmer 
Grazr - Easy feed grazing and sharing
http://www.grazr.com 


Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

DBD::mysql 4.005 Released

[Patrick Galbraith]

Dear DBD::mysql users and developers,

I'm pleased to announce the release of DBD::mysql 4.005! This release 
contains various fixes, per Changelog:


* Fixed mysql_warning issue  4.1 (reminders, patches, help from ROAM, 
(issue 25713)

* makerealclean patch from ROAM (issue #25714)
* sqlstate cleanup patch from ROAM
* Replaced all references to dbis-debug to use DBIc_TRACE_LEVEL(imp_xxh)
* Fix to dbd_st_destroy - added back previously removed 'free 
everything' code which
 had been moved to dbd_st_finish, causing a crash upon freeing of bind 
values
 after all rows resulting from one execution of a query have been 
fetched. This meant

 that next attempt to execute the prepared statement would segfault. This
 work thanks to Rainer Weikusat!
* Removed all 'FindNewTable' calls in all tests. Just use 't1' for all 
tests to

 simplify things.
* Better 'skip test' logic in some tests that were still running when 
they shouldn't

 have been, depending on version.

This release was possible with the help of:

ROAM, Rainer Weikusat, Scott Hildreth, DBI developer community


The release file's info:

 file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.005.tar.gz
 size: 122524 bytes
  md5: 39181a061348ad76b67c99326873ccd5

URL:

http://search.cpan.org/~capttofu/DBD-mysql-4.005/

Kind regards,

Patrick Galbraith

--
Patrick Galbraith, Senior Programmer 
Grazr - Easy feed grazing and sharing
http://www.grazr.com 


Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

DBD::mysql 4.004 Released!

[Patrick Galbraith]

Dear DBD::mysql users and developers,

I'm pleased to announce the release of DBD::mysql 4.004! This release 
contains various fixes, per Changelog:


* Work around a bug in old 3.23 servers by specifying NOT NULL for 
fields used

 as a primary key in tests. (Bug #20325, reported by Julian Ladisch)
* Add support for mysql_warning_count statement handle attribute. (Bug 
#25457,

 patch from Philip Stoev)
* Add support for mysql_multi_statements connection option. (RT #12322, 
based

 on patch from Doug Morris)
* Had to bump to 4.003 do to print statement in mysql.pm that made it
 into the dist. Even though you can delete a file on CPAN, you cannot
 re-upload it if it's the same name. Mea Culpa.
* UTF8-Flag not set with flag mysql_enable_utf8 and column collation 
utf8_bin patch,

 Joost Diepenmaat, (RT #24738)
* Fixed do_error definition (Scott Hildreth, Tim Bunce)
* Conversion of test suite to Test::More

This release was possible due to the efforts of:

Jim Winstead
Tim Bunce
Scott Hildreth
Joost Diepenmaat
Dave Rolsky
Philip Stoev
Doug Morris
Julian Ladisch

And the rest of the community, and anyone else I forgot to mention!

Thank you for using DBD::mysql and MySQL!

The files:

 file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.004.tar.gz
 size: 122247 bytes
  md5: ba89b04b003dec320c893f2553a98ede


Also:

http://search.cpan.org/~capttofu/DBD-mysql-4.004/

Kind regards,

Patrick Galbraith


--
Patrick Galbraith, Senior Programmer 
Grazr - Easy feed grazing and sharing
http://www.grazr.com 


Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

DBD::mysql 4.003 Released!

[Patrick Galbraith]

Dear DBD::mysql users and developers,

I'm pleased to announce the release of DBD::mysql 4.003! This release 
contains

various fixes including:

* Fix re-exec of Makefile.PL when forcing $ENV{LANG} to 'C'. (RT #25233,
 reported by Slaven Rezic)
* Rewrote table_info method to support all arguments (previously it would
 only ever return all of the tables in the current database, no matter what
 was specified)
* Fixed $DBD::mysql::VERSION to be a string instead of a float, which caused
 problems for certain locales
* Fixed bug #23974. $dbh-column_info now returns empty arrayref upon 
table  
  not existing.  Much thanks to Tim Bunce for help fixing the problem in

  mysql.pm vs. dbdimp.c
* Removed #ifdefs for do error (sqlstate being passed as last arg 
depending on

 version)
* Fixed insertid test to work with auto_increment_increment replication 
setup.

* Patch from Tim Bunce fixing do() not set $dbh-{Statement} attribute,
 which prevented DBD::Profile from giving correct results for calls to do()
 and causing ShowErrorStatement to possibly report the wrong statement 
in the

 error message
* Patch from Tim Bunce clearing out the sth attribute cache when switching
 between result, sets which prevented the adjustedment of NUM_OF_FIELDS
* Cleanup of several unused variables
* Added support for wildcards in last argument of column_info().
* Add mysql_is_auto_increment to results of column_info(). (Bug #26603,
 original patch from Dave Rolsky)
* Return the correct table type for both tables and views from the 
table_info()

 method. (Bug #26603, original patch from Dave Rolsky)
* Add implementation of foreign_key_info() (Bug #26604, original patch from
 Dave Rolsky, and final implementation based on Connector/J code)

Note: you may notice that the version went from 4.001 to 4.003. That's 
because there
was an issue with the 4.002 distribution file that needed to be fixed, 
and CPAN
doesn't allow uploading the same version file twice, hence the version 
was bumped.


This release was possible due to the efforts of:

Jim Winstead
Tim Bunce
Dave Rolsky

Thanks for bug reporting from

Slaven Rezic RT #25233
Allard Hoeve and others alerting me to problems with version being 
changed from
a string, which caused local issues for those who use ',' instead of '.' 
for decimal.


And anyone else I forgot to mention. Thank you for reporting bugs and 
sending

patches!

Also, thank you for using DBD::mysql!

Kind regards,

Patrick Galbraith

The file:

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.003.tar.gz
 size: 121582 bytes
  md5: 157f817d26a52aaaff61ce38f7043b95


--
Patrick Galbraith, Senior Programmer 
Grazr - Easy feed grazing and sharing
http://www.grazr.com 


Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

Re: Locale problems with bootstrapping DBD::mysql 4.001

[Patrick Galbraith]

Allard,

Good news - I have a fix for this in the upcoming version 4.002, which I 
will be releasing later today! Thanks for reporting this to me.


Kind regards,

Patrick

Allard Hoeve wrote:



Dear Patrick,

Thanks for writing and maintaining the wonderful piece of software 
called DBD::mysql! Perl wouldn't be much use to us without it :)


After upgrading to the recently released 4.001, we have run into some 
bootstrapping problems while running the software in Dutch locales. 
This seems to be the same problem as:


http://lists.mysql.com/perl/4028

Did you have any luck finding and fixing the problem? If so, could you 
please make an intermediate release? Right now we have to choose 
between having a choice of locales available or being able to use UTF8 
from MySQL properly.


Thanks!

Kind regards,

Allard Hoeve
Byte Internet




--
Patrick Galbraith, Senior Programmer 
Grazr - Easy feed grazing and sharing
http://www.grazr.com 


Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

Re: Type ulong not defined on MacOS X 10.4.8 for DBD::MySQL 4.00

[Patrick Galbraith]

Jonathan,

This is a problem with the client library that seems to expose itself on 
OS X and BSD systems, fixed in 5.0.26. I have no problem with 5.0.34 on 
my Mac.


Kind regards,

Patrick

Jonathan Leffler wrote:

Running [/Users/jleffler/perl/v5.8.8/bin/perl 
/Users/jleffler/perl/v5.8.8/bin/cpanp-run-perl Makefile.PL ]...

I will use the following settings for compiling and testing:

  cflags(mysql_config) = -I/usr/local/mysql/include -fno-common
  embedded  (mysql_config) =
  libs  (mysql_config) = -L/usr/local/mysql/lib -lmysqlclient 
-lz -lm

  mysql_config  (guessed ) = mysql_config
  nocatchstderr (default ) = 0
  nofoundrows   (default ) = 0
  ssl   (guessed ) = 0
  testdb(default ) = test
  testhost  (default ) =
  testpassword  (default ) =
  testsocket(default ) =
  testuser  (default ) =

To change these settings, see 'perl Makefile.PL --help' and
'perldoc INSTALL'.

Checking if your kit is complete...
Looks good
Using DBI 1.53 (for perl 5.008008 on darwin-2level) installed in 
/Users/jleffler/perl/v5.8.8/lib/site_perl/5.8.8/darwin-2level/auto/DBI/

Writing Makefile for DBD::mysql
Running [/usr/bin/make ]...
cp lib/DBD/mysql.pm blib/lib/DBD/mysql.pm
cp lib/DBD/mysql/GetInfo.pm blib/lib/DBD/mysql/GetInfo.pm
cp lib/DBD/mysql/INSTALL.pod blib/lib/DBD/mysql/INSTALL.pod
cp lib/Bundle/DBD/mysql.pm blib/lib/Bundle/DBD/mysql.pm
cc -c 
-I/Users/jleffler/perl/v5.8.8/lib/site_perl/5.8.8/darwin-2level/auto/DBI 
-I/usr/local/mysql/include -fno-common -DDBD_MYSQL_INSERT_ID_IS_GOOD 
-g  -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing 
-pipe -Wdeclaration-after-statement -I/usr/local/include -O3 
-DVERSION=\4.00\ -DXS_VERSION=\4.00\ 
-I/Users/jleffler/perl/v5.8.8/lib/5.8.8/darwin-2level/CORE   dbdimp.c

dbdimp.c: In function 'mysql_dr_connect':
dbdimp.c:1710: error: 'ulong' undeclared (first use in this function)
dbdimp.c:1710: error: (Each undeclared identifier is reported only once
dbdimp.c:1710: error: for each function it appears in.)
dbdimp.c:1710: error: parse error before numeric constant
make: *** [dbdimp.o] Error 1


Do you need any help identifying which header should be used to get 
'ulong' defined?  It isn't immediately obvious to me:


$ grep -l ulong /usr/include/*.h /usr/include/*/*.h
/usr/include/slapi-plugin.h
/usr/include/i386/types.h
/usr/include/openssl/x509v3.h
/usr/include/php/acconfig.h
/usr/include/ppc/types.h
/usr/include/tidy/fileio.h
/usr/include/tidy/platform.h
/usr/include/tidy/tidy.h
$





--
Patrick Galbraith, Senior Programmer 
Grazr - Easy feed grazing and sharing
http://www.grazr.com 


Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

DBD::mysql 4.001 Released!

[Patrick Galbraith]

Dear users and developers,

I'm pleased to announce the release of DBD::mysql 4.001! This fix comes 
on the heels of 4.00, and we've changed versioning a little bit per 
feedback. This release fixes many bugs that were lingering in rt.cpan.org


Per ChangeLog:

* Fix handling of unsigned integer values in result sets when using
 server-side prepared statements (they were not retrieved at all).
* Fix handling of signed integer values when using server-side prepared
 statements (they were being forced to unsigned values).
* Do not tell Perl that the contents of binary fields are UTF-8.
 [rt.cpan.org #22123], original patch by Joost Diepenmaat
* Fix double-free of bound parameters when freeing statements. (Bug #20559)
* Make sure to handle magical values in a couple of places. (Bug #20104)
* Update the hints about what to do when zlib is found missing while
 linking. (Bug #13803, reported by Philip Stoev)
* Explicitly initialize the MySQL client library to avoid possible race
 conditions in a multithreaded application. (Bug #21792)
* Fix warning when no connection attributes are passed to the connect
 method (Bug #17323, reported by Phil Randal)
* Removed redundant warnings when commit or rollback is called while
 AutoCommit is enabled. [rt.cpan.org #15802], reported by Tyler MacDonald
* Report correct type for decimal columns from MySQL 5.0 and later
 [rt.cpan.org #18294], reported by Ray Zimmerman
* Fix t/40bindparam.t to work when ANSI_QUOTES SQL_MODE is set.
 [rt.cpan.org #21521], reported by David Wheeler
* Return a statement handle with an error when column_info is called on
 a table that does not exist. (Bug #23974, patch by Philip Stoev)
* Fix handling of table names with characters that did not match /\w/ in
 the column_info method. (Bug #22005, reported by Philip Stoev)
* Fix handling of negative integers bound to a column marked as SQL_INTEGER.
 [rt.cpan.org #18976], patch from Mike Schilli.
* Add support for the primary_key_info method. [rt.cpan.org #8541]
* Fixed Bundle::DBD::mysql to only include modules required for using
 DBD::mysql, not the old Mysql package. [rt.cpan.org #24096]
* Updated Makefile.PL to not include files in .svn directories
* Fixed various compile warnings in mysql.xs (ISO C)
* Cleaned up stored procedure examples, made strict
* Fixed bug that blew away subsequent result sets if you fetched all 
rows, only in

 result sets that had more than one row
* Added test for bug #14979 
http://rt.cpan.org/Ticket/Display.html?id=14979, which still

 fails
* Tested with ALL mysql versions, fixed 40types, 40bind_param tests to 
work with 4.0, 4.1

* Fixed dbdimp.c to not test for MYSQL_DATA_TRUNCATED unless = mysql 5.0
* Tested with all versions - 4.0, 4.1, 5.0, 5.1

Again, thanks to all who have sent patches!

Special Thanks to:

Jim Winstead
Alexey Stroganov
Philip Stoev
Mike Schilli
David Wheeler
Ray Zimmerman
Tyler MacDonald
Phil Randal
Joost Diepenmaat

The uploaded file

   DBD-mysql-4.001.tar.gz

has entered CPAN as

 file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.001.tar.gz
 size: 116965 bytes
 md5: f1c70b2760365300873ccfa59cefceb2

Again, Thanks to all who have contributed and continue to contribute, and thank 
you for using DBD::mysql and MySQL!

Kind regards,

DBD::mysql maintainers



--
Patrick Galbraith, Senior Programmer 
Grazr - Easy feed grazing and sharing
http://www.grazr.com 


Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

DBD::mysql 4.00 released!

[Patrick Galbraith]

Dear users and developers,

I'm pleased to announce the release of DBD::mysql 4.00! This is the long 
awaited version 4.00 release which is the result of stabilising the 
former 3.000N_n tree. As you'll notice, the version has been changed to 
conform to best practices for perl versioning from the 3.000N to 4.00. 
This means future versions would be 4.01, 4.02, etc. The subversion tree 
has been cleaned out thoroughly (why wait for spring cleaning?!).


There are some significant changes, fixes and enhancements in this version:

* Added Alexey Stroganov's patch which fixes varying number of columns in
 multiple result sets. Added new test cases to 80procs.t based off his
 test script (bug #21028) (Thanks Alexey!). Also fixed 80procs.t to allow
 'CALL' to be prepared. Multiple result sets work properly now!

* Added Philip Stoev's patch for DATA_TYPE date and time columns (bug 
#23988)

 (Thanks Philip!)

* Reworked (for MySQL 4.0, which doesn't support sqlstate) Philip Stoev's
 patch for sqlstate, bug #23935 (Thanks Philip!)

* New Versioning! 4.00 now.

* Cleaned up much code that failed between MySQL Server versions.

* Turned off prepared statements by default. This mirrors the decision 
of other MySQL connector maintainers in that the C client API's 
implementation of prepared statements has some technical issues to be 
resolved before making prepared statements turned on by default. If you 
recall, the previous dev branch had them turned on by default. With this 
4.00 release, they are off by default, but can be turned on by appending

;mysql_server_prepare=1 in your DSN connection string.

* Tested this with MySQL 5.1, 5.0, 4.1, 4.0. Works with ALL these versions!

Alexey's notes about mutliple result set fixes:

Support of multiple result set was significantly improved:

 - now driver processes correctly result sets with different
   number of columns
 - processing of multiple result sets are not possible with 
   enabled server side prepare. As result CALL() statement
   will be executed with regular API as it may cause return 
   multiple result sets
 - added mysql_st_free_result_sets() routine that will 
   handle cleaning up all result sets produced by executed 
   statement



I want to thank these people:

Alexey Stroganov - his work on fixing multiple result sets is a great 
enhancement for DBD::mysql. Not to mention the prepared statement, 
embedded server code which he was a major developer of. He has taken on 
the role of co-maintainer of DBD::mysql.


Jim Winstead - he has fixed numerous bugs and is taking on 
co-maintainership of DBD::mysql. It was his advice on versioning and 
code management resulted in todays cleaned up release!


Philip Stoev - who sent patches listed above that fixed several issues 
in this release.


Anyone else in the community who has given feedback to help enhance this 
driver, and to the users and developers who use DBD::mysql!


Happy New Year! Keep the patches coming!

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.00.tar.gz
size: 114848 bytes
md5: 9520b2194c0423a531d8fa3ad104a3e7



--
Patrick Galbraith, Senior Systems Engineer 
MySQL AB, www.mysql.com


Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

Re: DBD::mysql - bug affecting storage of negative values in SQL_INTEGER and SQL_TINYINT

[Patrick Galbraith]

Hi!

I need to get this patch in, and apologise for not doing so sooner. I've 
been swamped with work on other projects within mysql, and even have a 
patch of mine that I wish to get in there... not to mention a patch for 
multiple result sets my comaintainer, Alexey Stroganov, has sent me!


When it rains, it pours!

Thank you for your kind words,

Patrick

ps. CC-ing the list so people know I know that they know that I need to 
get a release out soon ;)


Will Spooner wrote:


Hi Patrick,

Just to add weight to this issue; it also causes problems for projects 
that are based on the Ensembl code, including the two that I work on 
(Gramene, www.gramene.org, and MaizeSequence, www.maizeseqeunce.org), 
and a host of others listed here;


http://www.ensembl.org/info/about/ensembl_powered.html

We can work round the problem in most cases by downgrading to a local 
copy of DBD-mysql-2.9. This solution, however, is unsuitable for large 
multi-node compute clusters that we use for generating our data.


Many thanks for your efforts; DBD::mysql is almost always fantastic!

Will

On Wed, 6 Dec 2006, Glenn Proctor wrote:


Hi Patrick

I work on the open-source bioinformatics project Ensembl,
http://www.ensembl.org/ . The project is built on Perl and MySQL and
as you would expect we make heavy use of DBD::mysql.

We've had reports from some users of problems with storing negative
numbers; it looks like they are describing this bug:

http://rt.cpan.org/Public/Bug/Display.html?id=18976

The comments on the RT report would suggest that the patch that
MSCHILLI submitted made it in to 3.0008, but this doesn't seem to be
the case (I can provide a test script if necessary).

Do you know if the patch will make it in to the next release of
DBD::mysql? The bug in question is causing considerable problems for
us. If we can be of any assistance, or provide more information,
please let me know.

Regards

Glenn.




--
Patrick Galbraith, Senior Systems Engineer 
MySQL AB, www.mysql.com


Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

DBD::mysql 3.0008 and 3.0008 (Dev) released!

[Patrick Galbraith]

 that you would 
like to contribute to DBD::mysql.


The files:

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-3.0008.tar.gz
size: 116159 bytes
md5: 82b1f898ec26c1a12cc87e00b30f313f

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-3.0008_1.tar.gz
size: 115514 bytes
md5: 1175a095bc71ff736f05ec437832c8b8

Thank you for using MySQL and DBD::mysql!

Kind regards,

Patrick Galbraith

Re: MySQL, blobs, GIS

[Patrick Galbraith]

Mary Anderson wrote:


Hi all,
  I have a MySQL-perl-cgi-dbi application which would like to store images
and GIS info.  Will dbi running with DBD:MySQL support these?

  Thanks,

Mary Anderson
 


Mary,

Yes. Just as with blobs, those types are supported.

Kind regards,

Patrick

Re: Working on DBD::mysql 3.0008

[Patrick Galbraith]

Patrick Galbraith wrote:


Hi all,

Just a note to all who might've sent me patches, emailed me (thanks!). 
I was sick this week and also became emmersed in work on the federated 
storage engine. I am in the process of putting together a 3.0008 
release of DBD::mysql that I intend to get released next week.


That's all!

Kind regards,

Patrick


Hi all,

I'm about to release 3.0008/8_1, and have it in SVN at:

http://svn.perl.org/modules/DBD-mysql

The one thing I want to see is that it clears up memory bug issues on 
BSD variants.


Just to keep everyone up to date.

Kind regards,

Patrick

Working on DBD::mysql 3.0008

[Patrick Galbraith]

Hi all,

Just a note to all who might've sent me patches, emailed me (thanks!). I 
was sick this week and also became emmersed in work on the federated 
storage engine. I am in the process of putting together a 3.0008 release 
of DBD::mysql that I intend to get released next week.


That's all!

Kind regards,

Patrick

Re: Memory access problem with DBI or DBD-Mysql?

[Patrick Galbraith]

Federico Giannici wrote:


Patrick Galbraith wrote:


Sam Smith wrote:

Sam,

Thanks for the trace. I need to talk to someone about getting an 
OpenBSD box to test out potential solutions.



I'm available to test a prerelease version of the DBD driver.


Thanks!

It's my intent to roll up a release next week with this fix included. Do 
you also use the SVN tree for DBD::mysql?


Kind regards,

Patrick




Bye.

Re: Memory access problem with DBI or DBD-Mysql?

[Patrick Galbraith]

Federico Giannici wrote:

Federico,

Hmm One of the problems I had is that I didn't have a Open BSD box 
to test this out. Perhaps your second suggestion might be a solution to 
pursue. I would prefer that the argument to mysql_st_internal_execute 
take one type of argument.


BTW - how does it work if you use server-side prepare?

Kind regards,

Patrick


Hi Patrick,
I have seen that version 3.0007 has been released and it (should) have 
fixed that bug.

But...

1) In mysql_st_internal_execute() the bind_type_guessing variable is 
correctly set, but then it's NOT used: imp_dbh-bind_type_guessing 
is still used!


2) mysql_st_internal_execute() is used in only two places. Instead of 
doing all that tests at the beginning of the function to handle both 
cases (STH and DBH for the h parameter), why don't you change the 
type of the first parameter into a imp_dbh? Wouldn't everything be 
clearer this way?



Bye.



Federico Giannici wrote:


Hi Patrick,
are there any news about this bug?

Someone made me notice that there a few other tickets open on this 
bug (under i386 and amd64), like this one:


http://rt.cpan.org/Public/Bug/Display.html?id=20868

Thanks.



Patrick Galbraith wrote:


Federico,

That may be the issue. I have encountered this issue in other parts 
of the driver. There is a better way to do this, and I can look at 
making sure what is being passed is the same data object.


Thanks!

Patrick

Federico Giannici wrote:

Since there has been no reply to my previous message, I have done 
further investigations trying to find the problem.


Please note that my knowledge of DBI/DBD is almost null, so the 
followings are only simple suppositions.


I have seen that mysql_st_internal_execute() function is executed 
by both the do and execute methods. It seems that the problems 
are only with the do method and not with the execute, so I 
looked for the differences between them.


The main difference seems to be that execute passes a STATEMENT 
handle as first argument, while do passes a DATABASE handle. The 
mysql_st_internal_execute() function uses this handle to obtain the 
sth and then from this one the dbh.


So, my hypothesis is that if the initial handle is a database one, 
the sth (and the derived dbh) obtained from this is not a valid one!


Anybody can confirm (or negate) this wild hypothesis?

Thanks.

P.S.
I want to repeat that the problem manifest itself only under 
OpenBSD because of it's memory management that cause the program to 
segfault if try to access a non allocated memory. In other 
operating systems, a random value is get for 
imp_dbh-bind_type_guessing, which is almost irrelevant.



Federico Giannici wrote:

It seems to me that there is some kind of memory access problem 
with DBI or DBD-Mysql.


I'm using OpenBSD 3.9-stable amd64. On OpenBSD 3.3 i386 the 
problem didn't appeared. As you may know, recent version of 
OpenBSD have a new kind of memory handling that make the programs 
segfault when they try to access no (longer) allocated memory.


I'm using DBI 1.45 and DBD-Mysql 2.9008. I tried DBI 1.52 and 
DBD-Mysql 3.0006, but the problems were more frequent, so I 
remained to the old versions.


Here is the problem: frequently some do commands cause perl to 
crash with signal 11. The crashes seems to depend on a lot of 
factors. For example, loading more libraries could make the 
program to start working. I think it depends on the structure of 
the memory allocated to the program.


Here is the bt output of the core dump:

#0  0x5260a736 in mysql_st_internal_execute (h=0x4713b6e0, 
statement=0x479b7140, attribs=0x4aa5fd40, numParams=0, params=0x0,
cdaPtr=0x7f7c8610, svsock=0x43c90498, 
use_mysql_use_result=0) at dbdimp.c:1654
#1  0x52612da3 in XS_DBD__mysql__db_do (cv=0x40970b20) at 
mysql.xs:222
#2  0x50ddf07b in XS_DBI_dispatch () from 
/usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/DBI/DBI.so
#3  0x4a5a1c47 in Perl_pp_entersub () at 
/usr/src/gnu/usr.bin/perl/pp_hot.c:2890
#4  0x4a60899e in Perl_runops_standard () at 
/usr/src/gnu/usr.bin/perl/run.c:37
#5  0x4a5f744d in S_run_body (oldscope=1) at 
/usr/src/gnu/usr.bin/perl/perl.c:1936
#6  0x4a5f7231 in perl_run (my_perl=0x45356258) at 
/usr/src/gnu/usr.bin/perl/perl.c:1855

#7  0x00401afe in main ()

I have found the problem is caused by accessing 
imp_dbh-bind_type_guessing for the call to ParseParam() inside 
mysql_st_internal_execute().


I have verified that imp_dbh is NOT null, but trying to access 
any member make the program segfault. So maybe the pointer is a 
stale one?


I have not enough knowledge of DBI to make more debugging.


Bye.

Re: Memory access problem with DBI or DBD-Mysql?

[Patrick Galbraith]

d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8

alignbytes=4, prototype=define
  Linker and Libraries:
ld='cc', ldflags ='-Wl,-E '
libpth=/usr/lib
libs=-lm -lutil -lc
perllibs=-lm -lutil -lc
libc=/usr/lib/libc.a, so=so, useshrplib=true, libperl=libperl.so.10.1
gnulibc_version=''
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, 
ccdlflags='-Wl,-R/usr/libdata/perl5/i386-openbsd/5.8.8/CORE'

cccdlflags='-DPIC -fPIC ', lddlflags='-shared -fPIC '


Characteristics of this binary (from libperl):
  Compile-time options: PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO
  Built under openbsd
  @INC:
/usr/libdata/perl5/i386-openbsd/5.8.8
/usr/local/libdata/perl5/i386-openbsd/5.8.8
/usr/libdata/perl5
/usr/local/libdata/perl5
/usr/local/libdata/perl5/site_perl/i386-openbsd
/usr/libdata/perl5/site_perl/i386-openbsd
/usr/local/libdata/perl5/site_perl
/usr/libdata/perl5/site_perl
/usr/local/lib/perl5/site_perl
.





Regards
Sam


But...

1) In mysql_st_internal_execute() the bind_type_guessing variable 
is correctly set, but then it's NOT used: 
imp_dbh-bind_type_guessing is still used!


2) mysql_st_internal_execute() is used in only two places. Instead of 
doing all that tests at the beginning of the function to handle both 
cases (STH and DBH for the h parameter), why don't you change the 
type of the first parameter into a imp_dbh? Wouldn't everything be 
clearer this way?



Bye.



Federico Giannici wrote:


Hi Patrick,
are there any news about this bug?

Someone made me notice that there a few other tickets open on this 
bug (under i386 and amd64), like this one:


http://rt.cpan.org/Public/Bug/Display.html?id=20868

Thanks.



Patrick Galbraith wrote:


Federico,

That may be the issue. I have encountered this issue in other parts 
of the driver. There is a better way to do this, and I can look at 
making sure what is being passed is the same data object.


Thanks!

Patrick

Federico Giannici wrote:

Since there has been no reply to my previous message, I have done 
further investigations trying to find the problem.


Please note that my knowledge of DBI/DBD is almost null, so the 
followings are only simple suppositions.


I have seen that mysql_st_internal_execute() function is executed 
by both the do and execute methods. It seems that the problems 
are only with the do method and not with the execute, so I 
looked for the differences between them.


The main difference seems to be that execute passes a STATEMENT 
handle as first argument, while do passes a DATABASE handle. The 
mysql_st_internal_execute() function uses this handle to obtain 
the sth and then from this one the dbh.


So, my hypothesis is that if the initial handle is a database one, 
the sth (and the derived dbh) obtained from this is not a valid one!


Anybody can confirm (or negate) this wild hypothesis?

Thanks.

P.S.
I want to repeat that the problem manifest itself only under 
OpenBSD because of it's memory management that cause the program 
to segfault if try to access a non allocated memory. In other 
operating systems, a random value is get for 
imp_dbh-bind_type_guessing, which is almost irrelevant.



Federico Giannici wrote:

It seems to me that there is some kind of memory access problem 
with DBI or DBD-Mysql.


I'm using OpenBSD 3.9-stable amd64. On OpenBSD 3.3 i386 the 
problem didn't appeared. As you may know, recent version of 
OpenBSD have a new kind of memory handling that make the programs 
segfault when they try to access no (longer) allocated memory.


I'm using DBI 1.45 and DBD-Mysql 2.9008. I tried DBI 1.52 and 
DBD-Mysql 3.0006, but the problems were more frequent, so I 
remained to the old versions.


Here is the problem: frequently some do commands cause perl to 
crash with signal 11. The crashes seems to depend on a lot of 
factors. For example, loading more libraries could make the 
program to start working. I think it depends on the structure of 
the memory allocated to the program.


Here is the bt output of the core dump:

#0  0x5260a736 in mysql_st_internal_execute 
(h=0x4713b6e0, statement=0x479b7140, attribs=0x4aa5fd40, 
numParams=0, params=0x0,
cdaPtr=0x7f7c8610, svsock=0x43c90498, 
use_mysql_use_result=0) at dbdimp.c:1654
#1  0x52612da3 in XS_DBD__mysql__db_do (cv=0x40970b20) at 
mysql.xs:222
#2  0x50ddf07b in XS_DBI_dispatch () from 
/usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/DBI/DBI.so
#3  0x4a5a1c47 in Perl_pp_entersub () at 
/usr/src/gnu/usr.bin/perl/pp_hot.c:2890
#4  0x4a60899e in Perl_runops_standard () at 
/usr/src/gnu/usr.bin/perl/run.c:37
#5  0x4a5f744d in S_run_body (oldscope=1) at 
/usr/src/gnu/usr.bin/perl/perl.c:1936
#6  0x4a5f7231 in perl_run (my_perl=0x45356258) at 
/usr/src/gnu/usr.bin/perl/perl.c:1855

#7  0x00401afe

DBD::mysql 3.0007 and 3.0007_1 (Dev) released!

[Patrick Galbraith]

Dear DBD::mysql users and developers,

DBD::mysql version 3.0007 (stable, production) and 3.0007_1 (dev) have 
been released!


Version 3.0007 is the production version with server-side prepare
statements turned off by default, and 3.0007_1 is the development
version with server-side prepare statements turned on by default.

Changes in 3.0007/3.0007_1, from ChangeLog:

* Make sure to call dbd_st_finish when all rows from a statement handle
   have been fetched. (Bug #20153, Bug# 21607, as rt.cpan.org ticket #s
   20464, 21241) Jim Winstead
 * Patch from Steve Hay to fix bind_param to deal properly with insertion
   of a NULL into an INT or DOUBLE column using server-side prepare.
   Converted Steve's dbi.pl script to expose this problem to 40bindparam2
   test.
 * Fix to mysql_st_internal_execute to keep from passing undefined dbh
   handle member (bind_type_guessing) to parse_param causing crash on
   OpenBSD. Reported on rt.cpan.org (#20868) by Kyle Georg, as well as
   info from Sam Smith and Federico Giannici
 * Cleaned up tests to make sure test table is dropped at end of test.

Notes:

* To turn ON server-side prepared statements (only in 3.0007 non-dev 
release),
simply append ;mysql_server_prepare=1 to the connect string or via the 
driver
handle. Server-side prepared statements are turned off (emulated) by 
default in 3.0007.

Please refer to documentation for further details.

* To turn OFF server-side prepare statements (only in 3.0007_1 dev 
release) to have
emulated prepared statements, append ;mysql_emulated_prepare=1 in the 
connect string or
via the driver handle. Server-side prepared statements are turned on by 
default in 3.0007_1.

Please refer to documentation for further details.

* Very soon, I intend to turn on  server side prepared statement on by
default. I will test this thoroughly prior to making the switch,
so that users don't have any problems when upgrading, when the time comes.

* This prepared statement API is only available with MySQL server versions
4.1 and above, so if you're using an older version, you won't notice 
anything.

Though, be assured that even for the driver emulated handling of prepared
statements, I will continue to make sure the code is improved.

As the community, one think you can do if you are interested in helping
is to turn on server side prepare statements in 3.0007, or try the
development driver, 3.0007_1 to see if there are any problems. I've
tested the code as much as I can, but I know nothing tests code like
1000s of developers thinking of unique ways of using the driver that I
never could have imagined. If you find a bug, please report it to me, or
at http://bugs.mysql.com. There is also the rt.cpan.org website for 
reporting
issues, but I prefer http://bugs.mysql.com, since there is a good 
verification

process when a bug is reported there, and it's more visible to me.

Coveat: Please make sure you don't use a threaded Perl with this driver
on Solaris.

Again, if anyone has any problems or questions with the driver, please
feel free to email me, or especially post to dbi-users@perl.org , and if
you find bugs, please report them to http://bugs.mysql.com

These versions for this module can be found at CPAN:

http://search.cpan.org/dist/DBD-mysql/

Again, thanks to all who helped to report bugs for this release and 
provided patches.


Please feel free to email me directly if you need to get my attention to 
something that needs
attention, as well as if you feel that you would like to contribute to 
DBD::mysql.


Also, thank you for using MySQL and DBD::mysql!

Kind regards,

Patrick Galbraith

Re: DBD::mysql 3.0004+ not resetting $sth-{Active} after fetch

[Patrick Galbraith]

Addison, Mark wrote:

Mark,

Stumbled upon your email from June, and am very sorry to not have seen 
it and responded. I will have a fix for this within days with the 
release of DBD::mysql 3.0007/3.0007_1


Kind regards,

Patrick


Hello,

I upgraded DBD::mysql from 2.9006-1 to 3.0006-1 and suddenly started
getting
screens full of errors like:

prepare_cached(SELECT * FROM foo) statement handle
DBIx::ContextualFetch::st=HASH(0x971cc80) still Active at
/usr/share/perl5/Ima/DBI.pm line 381

After some digging it seems that the new version of the DBD::mysql is
failing
to reset the Active attribute on the sth after fetching all the rows.
The
following test script shows this.

#!env perl

use strict;
use warnings;
use DBI;

my $dbh=DBI-connect(
'DBI:mysql:host=localhost;database=test',
'test' = '',
{ RaiseError = 1, PrintError = 1 }
);

my $sql = 'SELECT 1';

my $sth = $dbh-prepare_cached($sql);
print Prepared active:,$sth-{Active},\n;
$sth-execute;
print Executed active:,$sth-{Active},\n;
while ( $sth-fetchrow_hashref ) { }
print Fetched  active:,$sth-{Active},\n;

# Prep again to see if we get Still Active warning
$sth = $dbh-prepare_cached($sql);

__END__

On a Debian System with
Linux jhary.itn.local 2.6.16-1-686 #1 Tue Mar 21 14:51:09 UTC 2006 i686
GNU/Linux
DBI 1.50
Perl v5.8.8 built for i486-linux-gnu-thread-multi
DBD::mysql 3.0006-1 or 3.0004-1

$ perl test-dbd-mysql.pl
Prepared active:
Executed active:1
Fetched  active:1
prepare_cached(SELECT 1) statement handle DBI::st=HASH(0x82bb238) still
Active
at test-dbd-mysql.pl line 26

If I drop back to DBD::mysql 2.9006-1 it works again.

$ perl test-dbd-mysql.pl
Prepared active:
Executed active:1
Fetched  active:

I can't test any other versions as the CPAN source won't complile on
this box
(Mysql deb doesn't seem to include mysql_config which the dbd make
wants)
and apt only offers me these versions.
Calling finish on the handle does reset the flag with any of the dbd
versions.
Playing with the mysql_server_prepare option doesn't seem to make any
difference.

Is anyone else seeing this? It seems odd that it didn't get spotted
through a
couple of release versions (although debian seem to be packaging the
developer
releases).

cheers,
mark
--






MARK ADDISON
WEB DEVELOPER

200 GRAYS INN ROAD
LONDON
WC1X 8XZ
UNITED KINGDOM
T +44 (0)20 7430 4678
F 
E [EMAIL PROTECTED]

WWW.ITN.CO.UK
Please Note:



Any views or opinions are solely those of the author and do not necessarily represent 
those of Independent Television News Limited unless specifically stated. 
This email and any files attached are confidential and intended solely for the use of the individual
or entity to which they are addressed. 
If you have received this email in error, please notify [EMAIL PROTECTED] 


Please note that to ensure regulatory compliance and for the protection of our 
clients and business,
we may monitor and read messages sent to and from our systems.

Thank You.
 

DBD::mysql 3.0006 and 3.0006_1 released

[Patrick Galbraith]

Dear DBD::mysql users,

DBD::mysql version 3.0006 (stable, production) and 3.0006_1 (dev) have 
been released! If you noticed, 3.0005/3.0005_1 was skipped because I had 
to correct the changelog and CPAN doesn't allow replacement of file uploads.


Version 3.0006 is the production version with server-side prepare
statements turned off by default, and 3.0006_1 is the development
version with server-side prepare statements turned on by default.

  * Fix dbd_st_finish in 3.0004 didn't clean up bind buffers resulting
in a memory leak. See eg/prepare_memory_usage.pl to see how this
manifests itself. Thanks to Jason Snell for giving me a good script
to reproduce this!
  * Fix to parse_params, mysql.xs dbh-do, and bind_param to deal with
passing substr to do for placeholder value. Thanks Martin Waite
for the patch to parse_params (extended to mysql.xs do and
bind_param for server-side prepared statements.


Note: to turn on server-side prepared statements, simply append
;mysql_server_prepare=1 to the connect string or via the driver
handle. Please refer to documentation for further details.

Notes:

* The development (3.0006_1) version supports multiple result sets from
stored procedures. Documentation and sample code (in the ./eg dir) is
included on how to use multiple result sets. Also, the perldoc has
information on multiple result sets.

* To turn off server-side prepare statements to have emulated prepared
statements, append ;mysql_emulated_prepare=0 in the connect string or
via the driver handle.

Thanks to Martin Waitem! He provided a great patch to parse_params, 
which emulated prepared statement code uses to translate placeholders 
into values. The fix he provided enables parse_params to handle passing 
things like substring to do using placeholders. I noticed that the 
same problem existed in the server-side prepared code, and his fix gave 
me the idea of how to fix it in the bind_param and mysql.xs do.


Also thanks to Jason Snell, who informed me of a memory leak and 
provided me with a script that ran execute in a continuous loop showing 
the memory leak! With this, I was able to see that finish wasn't 
freeing all of the bind members. This script is now in 
eg/prepare_memory_usage.pl. I would like to eventually put this in the 
test suite, if possible. I just need to find a way to have the test 
suite detect if memory usage increases as a loop iterates.


NOTICE: (as I said in the last release) Very soon, perhaps in a release 
or so, I intend to stabilise the dev release and make that the 
production release. This means that server

side prepared statements will be turned on by default. I intend to test
this thoroughly prior to making the switch, so that users don't have any
problems when upgrading, when the time comes. This prepared statement
API is only available with MySQL server versions 4.1 and above, so if
you're using an older version, you won't notice anything. Though, be
assured that even for the driver emulated handling of prepared
statements, I will continue to make sure the code is improved.

As the community, one think you can do if you are interested in helping
is to turn on server side prepare statements in 3.0006, or try the
development driver, 3.0006_1 to see if there are any problems. I've
tested the code as much as I can, but I know nothing tests code like
1000s of developers thinking of unique ways of using the driver that I
never could have imagined. If you find a bug, please report it to me, or
at http://bugs.mysql.com. I'll fix that bug and add test coverage for it.

Coveati: Please make sure you don't use a threaded Perl with this driver
on Solaris.

Again, if anyone has any problems or questions with the driver, please
feel free to email me, or especially post to dbi-users@perl.org , and if
you find bugs, please report them to http://bugs.mysql.com

These versions for this module can be found at CPAN:

http://search.cpan.org/dist/DBD-mysql/

The files:

DBD::mysql 3.0006

  file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-3.0006.tar.gz
  size: 114658 bytes
   md5: b6d46ea7df99800082a2d2480056b0ce

DBD::mysql 3.0006_1

  file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-3.0006_1.tar.gz
  size: 111796 bytes
   md5: 417f52d07338422ac16afc038bcc3434

Kind regards,

Patrick Galbraith

DBD::mysql 3.0004 and 3.0004_1 released

[Patrick Galbraith]

Dear DBD::mysql users,

This announcement comes a few days late, but DBD::mysql version 3.0004 
(stable, production) and 3.0004_1 (dev) have been released!


Version 3.0004 is the production version with server-side prepare 
statements turned off by default, and 3.0004_1 is the development 
version with server-side prepare statements turned on by default.


The changes in 3.0004, as listed in the changelog:
 * Fix dbd_st_finish which closed the handle prematurely (Martin Evans)
 * Compile issues (Martin Evans)
 * Fix to dbd_bind_ph to deal with numbers (ints, floats) correctly
   (Alexey Stroganov)
 * Test changes - bind_param 41 and 42

The changes to 3.0004_1 as listed in the changelog:

* Fix dbd_st_finish which closed the handle prematurely (Martin Evans)
 * Compile issues (Martin Evans)
 * Small change to get utf8 data returned. One still has to:
 $dbh-do(set character set utf8);
 $dbh-do(set names utf8);

   to get utf8 back and even then you only get it back if the
   column is defined as utf8 in mysql.
 * Fix to dbd_bind_ph to deal with numbers (ints, floats) correctly
   (Alexey Stroganov)
 * Test changes - bind_param 41 and 42
 * Turned off 70takeimp test

Note: to turn on server-side prepared statements, simply append 
;mysql_server_prepare=1 to the connect string or via the driver 
handle. Please refer to documentation for further details.


Notes:

* The development (3.0004_1) version supports multiple result sets from 
stored procedures. Documentation and sample code (in the ./eg dir) is 
included on how to use multiple result sets. Also, the perldoc has 
information on multiple result sets.


* To turn off server-side prepare statements to have emulated prepared 
statements, append ;mysql_emulated_prepare=0 in the connect string or 
via the driver handle.


*As listed in the second changelog, this code is now much better at 
handling SQL statements that aren't supported in the prepared statement 
C API, and silently deals with determining whether or not to use the 
prepared statement calls.


I really appreciate the help of Martin Evans, Alexey Stroganov, Henri 
Asseily, as well as the rest of the community in helping by giving 
patches and feedback about various issues with the driver. Thank you!


NOTICE: Very soon, perhaps in a release or so, I intend to stabilise the 
dev release and make that the production release. This means that server 
side prepared statements will be turned on by default. I intend to test 
this thoroughly prior to making the switch, so that users don't have any 
problems when upgrading, when the time comes. This prepared statement 
API is only available with MySQL server versions 4.1 and above, so if 
you're using an older version, you won't notice anything. Though, be 
assured that even for the driver emulated handling of prepared 
statements, I will continue to make sure the code is improved.


As the community, one think you can do if you are interested in helping 
is to turn on server side prepare statements in 3.0004, or try the 
development driver, 3.0004_1 to see if there are any problems. I've 
tested the code as much as I can, but I know nothing tests code like 
1000s of developers thinking of unique ways of using the driver that I 
never could have imagined. If you find a bug, please report it to me, or 
at http://bugs.mysql.com. I'll fix that bug and add test coverage for it.


Coveati: Please make sure you don't use a threaded Perl with this driver 
on Solaris.


Again, if anyone has any problems or questions with the driver, please 
feel free to email me, or especially post to dbi-users@perl.org , and if 
you find bugs, please report them to http://bugs.mysql.com


These versions for this module can be found at CPAN:

http://search.cpan.org/dist/DBD-mysql/

The files:

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-3.0004.tar.gz
size: 113043 bytes
md5: 5d328b9fdaf899eba6d72258242ad0a0

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-3.0004_1.tar.gz
size: 110175 bytes
md5: 4dfbd956417f5b036ab55defb8fdfac7

Kind regards,

Patrick Galbraith

Re: DBD::mysql 3.0003 and 3.0003_1 released

[Patrick Galbraith]

Paul DuBois wrote:

Paul,

Yes, I meant to add to mysql_server_prepare a =1 or =0! Thanks for 
catching that.


Kind regards,

Patrick


On 5/6/06 11:54, Patrick Galbraith [EMAIL PROTECTED] wrote:

 


Dear DBD::mysql users,

DBD::mysql version 3.0003 (stable, production) and 3.0003_1 (dev) have
been released!

Version 3.0003 is the production version with server-side prepare
statements turned off by default, and 3.0003_1 is the development
version with server-side prepare statements turned on by default.

The changes in 3.0003, as in the changelog, are:

* Fixed bug where if mysql_server_prepare is set and a prepare
   fails, only a warning is issued and no error text is
   available (Thanks Martin Evans!)
 * Added support for ParamValues and associated test (Martin Evans)
 * Removed declaration of int num_fields outside a block which
   was causing compilation error with some C compilers.
 * Fix to typo in Makefile.PL (Martin Evans)
 * Added mysql_stmt_reset for when mysql_stmt_execute fails
 * Added test for mysql_stmt_execute bug (Martin Evans)
 * Fixed syntax for create table ENGINE=InnoDB instead of type=innobase
 * Removed tests for old driver emulation

Note: to turn on server-side prepared statements, simply append
;mysql_server_prepare to the connect string or via the driver handle.
Please refer to documentation for further details.
   



Can you append =0 or =1 to indicate explicitly that you want this turned off
or on?

 

DBD::mysql 3.0003 and 3.0003_1 released

[Patrick Galbraith]

Dear DBD::mysql users,

DBD::mysql version 3.0003 (stable, production) and 3.0003_1 (dev) have 
been released!


Version 3.0003 is the production version with server-side prepare 
statements turned off by default, and 3.0003_1 is the development 
version with server-side prepare statements turned on by default.


The changes in 3.0003, as in the changelog, are:

* Fixed bug where if mysql_server_prepare is set and a prepare
   fails, only a warning is issued and no error text is
   available (Thanks Martin Evans!)
 * Added support for ParamValues and associated test (Martin Evans)
 * Removed declaration of int num_fields outside a block which
   was causing compilation error with some C compilers.
 * Fix to typo in Makefile.PL (Martin Evans)
 * Added mysql_stmt_reset for when mysql_stmt_execute fails
 * Added test for mysql_stmt_execute bug (Martin Evans)
 * Fixed syntax for create table ENGINE=InnoDB instead of type=innobase
 * Removed tests for old driver emulation

Note: to turn on server-side prepared statements, simply append 
;mysql_server_prepare to the connect string or via the driver handle. 
Please refer to documentation for further details.


The changes in 3.0003_1 are:

 * Removed old Msql-Mysql Driver emulation code - finally!!!
 * Removed string testing code for unsupported
   statements and now use error code returned from mysql_stmt_prepare, 
if statement not

   supported, toggle to mysql_emulated_prepare
 * Fixed bug where failed stmt execution caused later statements
   to fail with mysql_stmt_reset
 * Added tests for unsupported statements
 * Added test for test of failed statement with subsequent executes
   (thanks to Martin Evans!)
 * Added typo fix (Martin Evans)
 * Added support for ParamValues and associated test (Martin Evans)
 * Removed old emulated driver tests (HOORAY!)
 * Cleaned up debug printing code
 * Fixed syntax for create table ENGINE=InnoDB instead of type=innobase
 * Cleaned up tests

Notes:

* This version supports multiple result sets from stored procedures 
(Thanks to Guy Harrison!). Documentation and sample code (in the ./eg 
dir) is now included on how to use multiple result sets.


* To turn off server-side prepare statements append 
;mysql_emulated_prepare in the connect string or via the driver handle.


*As listed in the second changelog, this code is now much better at 
handling SQL statements that aren't supported in the prepared statement 
C API, and silently deals with determining whether or not to use the 
prepared statement calls.


I really appreciate the help of Martin Evans, as well as the rest of the 
community in helping by giving patches and feedback about various issues 
with the driver. Thank you!


The next version, I intend to stabilise the dev release and make that 
the production release. This will make it so that server side prepared 
statements are on by default. I intend to test this thoroughly prior to 
making the switch, so that users don't have any problems when upgrading, 
when the time comes. This prepared statement API is only available with 
MySQL server versions 4.1 and above, so if you're using an older 
version, you won't notice anything. Though, be assured that even for the 
driver emulated handling of prepared statements, I will continue to make 
sure the code is improved.


One last note: Please make sure you don't use a threaded Perl with this 
driver on Solaris. This is something I will add to the INSTALL notes and 
other documentation in the next release. Thanks to Leonid Kabanov for 
pointing this out.


Please, if anyone has any problems or questions with the driver, please 
feel free to email me, or especially post to dbi-users@perl.org , and if 
you find bugs, please report them to http://bugs.mysql.com


These versions for this module can be found at CPAN:

http://search.cpan.org/dist/DBD-mysql/

The files:

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-3.0003.tar.gz
size: 111761 bytes
md5: 7aa7c182ac59ab39cb7a32a8f9d6e945

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-3.0003_1.tar.gz
size: 109405 bytes
md5: e3d0e7f682e653d457c5f4d37a43f370

Thank you for using DBD::mysql!

Patrick Galbraith

Re: Adding utf8 support to DBD::mysql

[Patrick Galbraith]

Martin J. Evans wrote:

Martin,

Sure, I'll be glad to put in the code. If you can come up with tests, 
that's one thing we need. Whatever you like, and whatever works for you. 
I'll always give you due credit.


I also would like to know how to have a test end its while loop if a 
version doesn't support the server it's running against - if you know 
that, that would be fabulous. I came up with a way by querying the 
database, then checking if a string is /^4/ or /^3/ (stored procs), if 
it matches that, set $state = 1. I think there may be a better way! 
(well, that'd be Test::More I think)


Before I roll a dev release, I'd like to make sure I have looked at and 
added all of your patches that you have, as well as have tests for them.


Again, Thank you!

Patrick


Patrick Galbraith wrote:


Martin J. Evans wrote:

Martin,

Thanks much! This is dbdimp.c, right?


Yes


I  will add this tomorrow (not working today),



and I'm stricly not working tomorrow - bank holiday - but it is likely
I'll find time to do something.

and test it out. If everything is a go, then I'll roll up a dev 
3.0003_1 releaseAlso, I've mentioned giving you write access to SVN 
for DBD::mysql - do you want that? Also, what is your cpan username?



Argh, tend to be a submitter/commentor rather than a creator.
I've written DBIx::Log4perl but still have not submitted it
as I have not yet got a cpan username.

If you are happy giving me write access to DBD::mysql I'm happy to
contribute although I think you've got most of my stuff now. If
all it means is getting a cpan username and that is straight forward
I'll do that also.

The utf8 patch is very much a quick hack but it you were to submit
the other patches to dbd::mysql first I'd happily investigate/test
further. The reason I say this is that I'm finding it increasingly
difficult to submit patches on top of patches that are not comitted
yet.

Martin



Kind regards,

Patrick


Shamelessy stolen from Michael Kröll and against a patch on dbd::mysql
on subversion I've sent to Patrick which is not committed yet:

@@ -2915,6 +2914,9 @@
  if (dbis-debug = 2)
PerlIO_printf(DBILOGFP, st_fetch string data %s\n, 
fbh-data);

  sv_setpvn(sv, fbh-data, fbh-length);
+  if (is_high_bit_set(fbh-data)) {
+  SvUTF8_on(sv);
+  }
  break;
@@ -2968,6 +2970,10 @@
  {--len; }
}
sv_setpvn(sv, col, len);
+if (is_high_bit_set(col)) {
+SvUTF8_on(sv);
+}
+   @@ -3881,3 +3901,11 @@
  return
sv_2mortal(my_ulonglong2str(mysql_insert_id(((imp_dbh_t*)imp_dbh)-mysql))); 


}
#endif
+
+int is_high_bit_set(val)
+char *val;
+{
+while (*val)
+if (*val++  0x80) return 1;
+return 0;
+}


would appear to make the previous code (below and without the 
Encode) I posted

work fine.

I hasten to add I've not tested this much (other than the posted 
test code).


What I'm personally interested in is whether retrieving utf data from
DBD::mysql and pushing it through JSON, JSON-objToJson works and I 
cannot

easily test this until Tuesday.

If Patrick can commit my previous changes I'll test this more.

Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com


On 30-Apr-2006 Martin J. Evans wrote:
 

I hope I'm not muddying the waters but dbd::mysql UTF support for 
returned

data (not metadata) seems to be nearly there. I need UTF8 support on
at least inserted and returned results-sets although I'm less bothered
by UTF8 table/column names. It would seem that if you define your 
table as

using UTF8 then insertion is not a problem but retrieval is. The
following code nearly works - it is just the setting of the utf8 
flag on

the returned data that is wrong:

#!/usr/bin/perl -w
use strict;
use DBI qw(:utils);
use charnames ':full';
use Encode;

print Is utf8::is_utf8 defined: , defined utf8::is_utf8, \n;
print Is utf8::valid defined: , defined utf8::valid, \n;
my $str = \x{263a}xxx . chr(0x05d0) . \N{ARABIC LETTER ALEF}; # 
smiley

print join( , unpack(H*, $str)), \n;
print length(str) = , length($str), \n;
print bytes::length(str) = , bytes::length($str), \n;

print utf8::is_utf8 = , utf8::is_utf8($str) ? 1 : 0, \n;
print data_string_desc: , data_string_desc($str),\n;

open OUT, uni.out;
binmode(OUT, :utf8);
print OUT $str\n;
# data written to uni.out is UTF8

my $dbh = DBI-connect(dbi:mysql:test, xxx, xxx);
# there are posts on dbi-user as to whether both or either of
# the following should be set
$dbh-do(set character set utf8);
$dbh-do(set names utf8);
$dbh-do(drop table if exists utf);
$dbh-do(create table utf (a char(100)) default charset utf8);
my $sth = $dbh-prepare(insert into utf values (?));
$sth-execute($str);
$sth = $dbh-prepare(select * from utf);
$sth-execute;

my @row = $sth-fetchrow_array;
print data_string_desc (after fetch): , 
data_string_desc($row[0]),\n;

# the following shows we'e got the right data back
# but perl does not know

Re: Adding utf8 support to DBD::mysql

[Patrick Galbraith]

Martin J. Evans wrote:


Patrick Galbraith wrote:


Martin J. Evans wrote:

Martin,

Sure, I'll be glad to put in the code. If you can come up with tests, 
that's one thing we need. Whatever you like, and whatever works for 
you. I'll always give you due credit.



Slightly confused as I think I provided tests for the changes I've 
submitted.


Martin,

Yes, I know - you've given plenty of tests - I meant in general, that we 
could use more tests overall. Sorry for that misunderstanding ;)




Was there some changes I omitted tests for? (other than the utf8 hack
I just posted).

I noticed there were to dos in the the TODO file for more tests -
I can try and knock a few of those off during a free moment.

I also would like to know how to have a test end its while loop if a 
version doesn't support the server it's running against - if you know 
that, that would be fabulous. I came up with a way by querying the 
database, then checking if a string is /^4/ or /^3/ (stored procs), 
if it matches that, set $state = 1. I think there may be a better 
way! (well, that'd be Test::More I think)



I'll look in to it but don't know off the top of my head.
I saw something in the Testing() fn about skipping/ignoring tests.

Before I roll a dev release, I'd like to make sure I have looked at 
and added all of your patches that you have, as well as have tests 
for them.



Great - let me know when it is in subversion and I'll take another look.



Thanks again! Sorry if you took my last mail to main that you didn't 
give tests!


Kind regards,

Patrick



Martin


Again, Thank you!

Patrick


Patrick Galbraith wrote:


Martin J. Evans wrote:

Martin,

Thanks much! This is dbdimp.c, right?




Yes


I  will add this tomorrow (not working today),





and I'm stricly not working tomorrow - bank holiday - but it is likely
I'll find time to do something.

and test it out. If everything is a go, then I'll roll up a dev 
3.0003_1 releaseAlso, I've mentioned giving you write access to SVN 
for DBD::mysql - do you want that? Also, what is your cpan username?





Argh, tend to be a submitter/commentor rather than a creator.
I've written DBIx::Log4perl but still have not submitted it
as I have not yet got a cpan username.

If you are happy giving me write access to DBD::mysql I'm happy to
contribute although I think you've got most of my stuff now. If
all it means is getting a cpan username and that is straight forward
I'll do that also.

The utf8 patch is very much a quick hack but it you were to submit
the other patches to dbd::mysql first I'd happily investigate/test
further. The reason I say this is that I'm finding it increasingly
difficult to submit patches on top of patches that are not comitted
yet.

Martin



Kind regards,

Patrick

Shamelessy stolen from Michael Kröll and against a patch on 
dbd::mysql

on subversion I've sent to Patrick which is not committed yet:

@@ -2915,6 +2914,9 @@
  if (dbis-debug = 2)
PerlIO_printf(DBILOGFP, st_fetch string data %s\n, 
fbh-data);

  sv_setpvn(sv, fbh-data, fbh-length);
+  if (is_high_bit_set(fbh-data)) {
+  SvUTF8_on(sv);
+  }
  break;
@@ -2968,6 +2970,10 @@
  {--len; }
}
sv_setpvn(sv, col, len);
+if (is_high_bit_set(col)) {
+SvUTF8_on(sv);
+}
+   @@ -3881,3 +3901,11 @@
  return
sv_2mortal(my_ulonglong2str(mysql_insert_id(((imp_dbh_t*)imp_dbh)-mysql))); 


}
#endif
+
+int is_high_bit_set(val)
+char *val;
+{
+while (*val)
+if (*val++  0x80) return 1;
+return 0;
+}


would appear to make the previous code (below and without the 
Encode) I posted

work fine.

I hasten to add I've not tested this much (other than the posted 
test code).


What I'm personally interested in is whether retrieving utf data from
DBD::mysql and pushing it through JSON, JSON-objToJson works and 
I cannot

easily test this until Tuesday.

If Patrick can commit my previous changes I'll test this more.

Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com


On 30-Apr-2006 Martin J. Evans wrote:
 

I hope I'm not muddying the waters but dbd::mysql UTF support for 
returned

data (not metadata) seems to be nearly there. I need UTF8 support on
at least inserted and returned results-sets although I'm less 
bothered
by UTF8 table/column names. It would seem that if you define your 
table as

using UTF8 then insertion is not a problem but retrieval is. The
following code nearly works - it is just the setting of the utf8 
flag on

the returned data that is wrong:

#!/usr/bin/perl -w
use strict;
use DBI qw(:utils);
use charnames ':full';
use Encode;

print Is utf8::is_utf8 defined: , defined utf8::is_utf8, \n;
print Is utf8::valid defined: , defined utf8::valid, \n;
my $str = \x{263a}xxx . chr(0x05d0) . \N{ARABIC LETTER ALEF}; 
# smiley

print join( , unpack(H*, $str)), \n;
print length(str) = , length($str), \n;
print bytes::length(str) = , bytes

Re: Help required from dbd::mysql maintainers/authors re MYSQL_VERSION_ID and SERVER_PREPARE_VERSION

[Patrick Galbraith]

Martin,

Thanks for the info. Do you have a script that does this? 
mysql_st_execute41 should be called if mysql supports prepared 
statements, that is, =  SERVER_PREPARE_VERSION. I'm a bit suprised it 
works, but I think I have code that catches it even if it doesn't 
support prepared statements, so mysql_st_execute41 might have better 
handling, even for versions  4.1. Please send whatever script you have 
to reproduce this. I'd like to see why it works where it shouldn't and 
where it doesn't where it should.


Kind regards,

Patrick

Martin J. Evans wrote:


Hi,

I could really do with a little assistance form the dbd::mysql 
maintainers or authors please.


I am investigating the issue I reported here with execute_array or all 
executes failing after one execute fails.


i.e.
create table test (a int primary key)
prepare(insert into test values(?)
execute(1) - OK
execute(2) - OK
execute(1) - fails but expected
execute(3) - fails but row inserted and not expected to fail

It appears this has something to do with whether MYSQL_VERSION_ID is 
= SERVER_PREPARE_VERSION.


My myql is 50015 and my client lib is also 50015 - as client and 
server are on the same machine.

SERVER_PREPARE_VERSION is 40103 (in dbimp.h)

When I run with dbd::mysql (from 3.0002_4) it fails.
When I turn all comparisons of MYSQL_VERSION_ID = 
SERVER_PREPARE_VERSION around so it is  it works.
Can someone tell my if dbd_st_execute is supposed to call 
mysql_st_internal_execute41 for versions of MySQL

40103 and lower or the opposite way around. I suspect it should be:

if MYSQL_VERSION_ID  SERVER_PREPARE_VERSION
 use mysql_st_internal_execute41

because other places in the code do things like:

#if MYSQL_VERSION_ID  SERVER_PREPARE_VERSION   if 
(mysql_real_query(imp_dbh-mysql, COMMIT, 6))

#else
 if (mysql_commit(imp_dbh-mysql))
#endif

because functions like mysql_commit were introduced in 4.1

I'd greatly appreciate any help here as I'm desparately trying to make 
this work and trying very hard to feedback problems and fixes to 
DBD::mysql.


Martin

Re: Message from Maintainer to DBD::mysql users, developers

[Patrick Galbraith]

Martin,

Thanks! I'll look for this patch and test it out, and hopefully do a dev 
release. I agree that this is a priority.


regards,

Patrick

Martin J. Evans wrote:


Tim Bunce wrote:


On Wed, Mar 29, 2006 at 09:58:16AM -0800, Mark Hedges wrote:


On Wed, 29 Mar 2006, Tim Bunce wrote:


On Wed, Mar 29, 2006 at 10:53:56AM +0200, Peter J. Holzer wrote:


On 2006-01-31 01:24:18 +0100, Patrick Galbraith wrote:

I apologise for what might seem somewhat of a bit of neglect on 
my part to get some features into DBD::mysql, features such as 
UTF support, some bugs in 3.0002_4. I've been super busy on some 
other projects, but have finished one of them and have today 
started to go through my mail in order to start addressing some 
needs of DBD::mysql.


I'm wondering if it might help to discuss within this list what 
priorities users would like to see addressed in DBD::mysql, so I 
could come out with some sort of road map.



Sorry for the late reply, but I just stumbled across it again 
recently:


Since mysql supports different charsets per table and even per 
column,

I'd like an option to automatically convert them to and from perl's
internal UTF-8 encoding.

(Actually, I'd like that to be the default behaviour, but it probably
would break a lot of existing scripts, so it should be an option at
first)



I think that translates into just asking DBD::mysql to set the
'connection charset' to utf8 and then mysql server will look after the
conversions for you.



Hmmm, I tried setting the default connection charset:

   /etc/my.cnf:
   [client]
   port= 3306
   socket  = /var/run/mysqld/mysqld.sock
   default-character-set=utf8

   mysql show variables like 'character_set_connection';
   +--+---+
   | Variable_name| Value |
   +--+---+
   | character_set_connection | utf8  |
   +--+---+
   1 row in set (0.00 sec)

But the scalars selected from a utf8 field still do not have the
utf8 flag set in perl.




Perhaps DBD::mysql doesn't yet support utf8. My reply above assumed
that it did. [...later...] I see no mention of utf8 or unicode in the
DBD::mysql docs. That's sad.

Tim.



There was a patch for utf8 posted either here or on the mysql perl
list within the last week. I'm at home now so can't easily find
it right now but it sort of suggested to me that someone was
using utf8.

Martin

Message from Maintainer to DBD::mysql users, developers

[Patrick Galbraith]

Greetings all!

I apologise for what might seem somewhat of a bit of neglect on my part 
to get some features into DBD::mysql, features such as UTF support, some 
bugs in 3.0002_4. I've been super busy on some other projects, but have 
finished one of them and have today started to go through my mail in 
order to start addressing some needs of DBD::mysql.


I'm wondering if it might help to discuss within this list what 
priorities users would like to see addressed in DBD::mysql, so I could 
come out with some sort of road map.


Just some thoughts, and a note to let all of you know that I'm here!

Kind regards,

Patrick Galbraith

Re: DBD::mysql dbdimp.c does not compile - solution

[Patrick Galbraith]

Martin J. Evans wrote:


Martin,

Thanks much!

I'll be rolling a 3.0002_4 dev release really soon with this fix, also 
with multi-result set support.


Kind regards,

Patrick


oops, forgot to say this was the DBD::mysql developers release 3.0002_3.

Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development


On 02-Nov-2005 Martin J. Evans wrote:
 


Just in case this helps anyone else.

I've just tried DBD::mysql for the first time and it failed to compile with
gcc
2.95.3. It appears there are functions in dbdimp.c which declare variables
after code in:


1. dbd_st_prepare, code in #if before searchptr etc declared:

{
 int i;
 SV **svp;
 D_imp_dbh_from_sth;

#if MYSQL_VERSION_ID = SERVER_PREPARE_VERSION
/* Set default value of 'mysql_emulated_prepare' attribute for sth from dbh
*/
 imp_sth-use_server_side_prepare= imp_dbh-use_server_side_prepare;
 if (attribs)
 {
   svp= DBD_ATTRIB_GET_SVP(attribs, mysql_emulated_prepare, 22);
   imp_sth-use_server_side_prepare = (svp) ?
 SvTRUE(*svp) : imp_dbh-use_server_side_prepare;
 }

 char *searchptr;
 int col_type;
 int limit_flag= 0;
 int statement_length= 0;
 MYSQL_BIND *bind, *bind_end;
 imp_sth_phb_t *fbind;

2. same as 1, in mysql_st_internal_execute

 else
 {
   D_imp_sth(h);
   D_imp_dbh_from_sth;
   bind_type_guessing= imp_dbh-bind_type_guessing;
 }

 char *salloc = parse_params(svsock,
 sbuf,
 slen,
 params,
 num_params,
 bind_type_guessing);

I fixed be moving the declarations.

Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development
   

Re: [Fwd: Problems installing DBD::mysql]

[Patrick Galbraith]

On Jul 14, 2005, at 7:48 PM, Scott T. Hildreth wrote:


client = mysql  Ver 12.22 Distrib 4.0.18, for suse-linux (i686)

Server = mysql  Ver 11.18 Distrib 3.23.58, for portbld-freebsd4.1.1 
(i386)


  ...which is the problem, I didn't realize the server version was 
that old.


  I ran all test successfully against

Server = mysql  Ver 14.7 Distrib 4.1.11, for portbld-freebsd5.3 (i386)

 ** Will the current DBD::mysql not work with mysql  4.0 ?




Sorry for taking some time to respond - I don't think so. The client 
libs are too old. You'd have to use an older DBD::mysql.


regards,

Patrick



On Thu, 2005-07-14 at 19:01 +0200, Patrick Galbraith wrote:

Scott,

First of all, could you please give me some information such as client
lib version (where did you obtain it from?), the version of the server
you are connecting to, OS (type, version, hardware). That's a very
strange error, because I do know for certain that I the AutoCommit
attribute is implemented, both for 4.0, 4.1, and 5.0 MySQL server
versions.

Kind regards,

Patrick

On Jul 14, 2005, at 6:53 PM, Scott T. Hildreth wrote:


Sorry to bother you, but my posts to DBI-Users is taking a
while...again.  I've installed DBD::mysql many of times. I know
I am missing something obvious here, but can't seem to think today.

  Any help would be appreciated,

   STH
--
Scott T. Hildreth [EMAIL PROTECTED]

From: Scott T. Hildreth [EMAIL PROTECTED]
Date: July 14, 2005 6:34:48 PM CEST
To: dbi-users@perl.org dbi-users@perl.org
Subject: Problems installing DBD::mysql
Reply-To: [EMAIL PROTECTED]


If I missed something in the archives I apologize.

I am trying to install DBD::mysql 3.0002, (I have client only
libraries), when I run make test, all but test 1 fail with,

DBD driver has not implemented the AutoCommit attribute

...this happens on the connect.  I set the testhost name
and can connect from the command line.

Any Ideas?

  Thanks.
--
Scott T. Hildreth [EMAIL PROTECTED]




Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com

Whatever action a great man performs, common men follow. Whatever
standards he sets by exemplary acts, all the world pursues  --
Bhagavad Gita

--
Scott T. Hildreth [EMAIL PROTECTED]


Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com

Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Re: [Fwd: Problems installing DBD::mysql]

[Patrick Galbraith]

Scott,

First of all, could you please give me some information such as client 
lib version (where did you obtain it from?), the version of the server 
you are connecting to, OS (type, version, hardware). That's a very 
strange error, because I do know for certain that I the AutoCommit 
attribute is implemented, both for 4.0, 4.1, and 5.0 MySQL server 
versions.


Kind regards,

Patrick

On Jul 14, 2005, at 6:53 PM, Scott T. Hildreth wrote:


Sorry to bother you, but my posts to DBI-Users is taking a
while...again.  I've installed DBD::mysql many of times. I know
I am missing something obvious here, but can't seem to think today.

  Any help would be appreciated,

   STH
--
Scott T. Hildreth [EMAIL PROTECTED]

From: Scott T. Hildreth [EMAIL PROTECTED]
Date: July 14, 2005 6:34:48 PM CEST
To: dbi-users@perl.org dbi-users@perl.org
Subject: Problems installing DBD::mysql
Reply-To: [EMAIL PROTECTED]


If I missed something in the archives I apologize.

I am trying to install DBD::mysql 3.0002, (I have client only
libraries), when I run make test, all but test 1 fail with,

DBD driver has not implemented the AutoCommit attribute

...this happens on the connect.  I set the testhost name
and can connect from the command line.

Any Ideas?

  Thanks.
--
Scott T. Hildreth [EMAIL PROTECTED]




Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com

Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

DBD::mysql 3.0002 released

[Patrick Galbraith]

Dear developers,

Version 3.0002 DBD::mysql, the perl DBI interface to MySQL,has just 
been released!


Version 3.0002 Fixes the problem with the package had problems being 
built with  MySQL 4.1, as was fixed on 3.0001_3. Many of you informed 
me about this issue and I'm very thankful for your help!


Thanks to:

Tom Parkison, Anup Singh, Sergey Skvortsov, and other users!

This should stabilise the 3.0002 tree for some time, and the production 
releases won't be as frequent. I will be working on adding features to 
the 3.0002 Dev tree, which will include server side prepare being 
turned on by default, multiple result set support (for stored 
procedures in 5.0), as well as not having to emulate LIMIT placeholders 
(fixed in 5.0.x), plus many other enhancements. As always, you are 
welcome to send me patches - I enjoy working with the community in 
improving and enhancing DBD::mysql!


Please, if anyone has any problems or questions with the driver, please 
feel free to email me, or especially post to dbi-users@perl.org (if you 
are subscribed of course!), and if you find bugs, please report them to 
http://bugs.mysql.com


These versions for this module can be found at CPAN:

http://search.cpan.org/dist/DBD-mysql/

The files:

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-3.0002.tar.gz
size: 130077 bytes
md5: df70ba084c97f5f7c2a997c3de2f0ad0

Again, as always, thank you for using DBD::mysql and MySQL!

Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com

Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

DBD:mysql 3.0001 and 3.0001_3 Released

[Patrick Galbraith]

Version 3.0001_3 Dev release and Version 3.0001 DBD::mysql, the perl 
DBI interface to MySQL,

have just been released.

Version 3.0001 is a production version with server-side prepared 
statements turned off by default during 'make test', and version 
3.0001_3 is a development version with server-side prepared statements 
turned on during 'make test'. Even though the code supports server side 
prepared statements, you must have version 4.1.3 of MySQL for them to 
work, otherwise the driver simply emulates prepared statements.


With any new version, there are issues that have to be ironed out, and 
I realise that many of you have found some issues since the release of 
3., and I'm extremely grateful for the feedback that I've been 
getting in solving many of these problems.


Thanks to:

Brad Choate, Six Apart Ltd. - Reporting and sending me a test script 
that revealed the bug where updating and inserting escaped double and 
single quotes would cause segfault


Anup Singh and Tom Parkison - Reporting the issue with problems when 
compiling against client versions less than 4.1.3


Please, if anyone has any problems or questions with the driver, please 
feel free to email me, or especially post to dbi-users@perl.org (if you 
are subscribed of course!), and if you find bugs, please report them to 
http://bugs.mysql.com


These versions for this module can be found at CPAN:

http://search.cpan.org/dist/DBD-mysql/

The files:

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-3.0001.tar.gz
  size: 129946 bytes
   md5: 70d1d33e906e896194a747fc23c22f1f

file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-3.0001_3.tar.gz
  size: 130279 bytes
   md5: 174a82efe4db20492228e97473dec81a

Again, as always, thank you for using DBD::mysql and MySQL!

Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com

Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Development Version 3.0001_1 DBD::mysql released

[Patrick Galbraith]

Version 3.0001_0 Dev release DBD::mysql, the perl DBI interface to 
MySQL,
has just been released. This version fixes windows compilation issues 
as well

as some other issues found in both 2.900x and 3..

Thanks to:

Steve Hay, for his excellent help on Windows compilation issues.
Bodo Bergmann for other crucial issues he found compiling on AIX.

One of the key differences with this release is that server-side 
prepared statements (not emulated in the driver, but prepared on the 
server using the mysql prepared statement C-API) are compiled and 
during make test, turned on by default. In regular use, you still need 
to set :mysql_server_prepare=1 at the end of your DSN string in order 
to use prepared statements.


Note: Prepared statements will only work on the server with MySQL 
versions 4.1.3 and greater. If you have an earlier version, it will 
default back to driver-emulated prepared statements.


The module can be found at CPAN:

http://search.cpan.org/dist/DBD-mysql/

Checksum for the tarballl:

md5: 66bd6057709d704cf9d1bca606cb6af2

Feedback and bug reporting for DBD::mysql

http://lists.cpan.org/showlist.cgi?name=dbi-users
http://lists.cpan.org/showlist.cgi?name=dbi-dev
http://lists.mysql.com/perl
http://bugs.mysql.com

As always, thank you for using DBD::mysql and MySQL!

Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com

Those who fear climbing mountains
Shall live forever in the holes - Arab Poet

DBD::mysql 3.000 Released

[Patrick Galbraith]

Dear DBD::mysql Users and Developers,

I am pleased to announce the release of DBD::mysql 3., now 
available via CPAN!


Included in this release:

* Support for prepared statements!
* Embedded server support
* LIMIT placeholder support (emulated)
* Various Bug Fixes

This release is essentially what has been available as 2.9015, and is 
now the main release. Being that prepared statement support and 
embedded server are new features, support for both is turned off by 
default, and can be compiled into the driver by:


perl Makefile.pl --ps-protocol (to compile in prepared server support)
perl Makefile.pl --force_embedded (to compile in embedded server 
support)


Prior to running 'make test' after building, the test suit can be run 
utilising the compiled-in prepared statement API by exporting:


export MYSQL_SERVER_PREPARE=1

Once either is compiled into the driver and DBD::mysql installed, to 
use either in your application code, please refer to the documentation 
(via perldoc) to use each. There you will find documentation on how to 
take advantage of these new features.


If you have any questions, please feel free to ask on the various 
mailing lists.


Thank you for using DBD::mysql!

Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com

Those who fear climbing mountains
Shall live forever in the holes - Arab Poet

Re: Connection Issue with DBI::DBD::mysql

[Patrick Galbraith]

Hi there!

What if you use the command line client to make this same connection - 
can you connect successfully?


Kind regards,

Patrick

On Jun 22, 2005, at 8:40 PM, [EMAIL PROTECTED] wrote:


Hi everyone,
Trying to connect to a MySQL database from a Linux Server using
 PERL to a Windows Machine with a MySQL database (5.0.6). I can
 connect successfully on the windows box but cannot on the Linux
 server! I ran a SQLTRACE (DBD) with the following output:
 imp_dbh-connect: dsn =
 database=userdb:hostname=192.168.2.113:port=3307, uid = user1, pwd
 = user1 imp_dbh-MyLogin: dbname = userdb, uid = user1, pwd =
 user1,host = 192.168.2.113, port = 3307 imp_dbh-mysql_dr_connect:
 host = 192.168.2.113, port = 3307, uid = user1, pwd = user1

 imp_dbh-mysql_dr_connect: client_flags = 2

 imp_dbh-mysql_dr_connect: -Access denied for user
 'user1'@'192.168.3.90' (using password: YES) error 1045 recorded:
 Access denied for user 'user1'@'192.168.3.90' (using password: YES)

 What disturbs me is that the return error comes back with a
 different IP address than what I sent out. Anyone have any idea as
 to why? That would seem to be the problem with the access denied!
The machine address that issues the connect is 192.168.3.190 but the 
address comming back is totally different.


George

__
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at 
http://isp.netscape.com/register


Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp


Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com

Those who fear climbing mountains
Shall live forever in the holes - Arab Poet

Re: DBD::mysql 2.9007 and DBD::mysql 2.9015_3 (beta) released

[Patrick Galbraith]

Steve,
Thank you so much for these patches! I love open source!
I'm sorry about forgetting about the removal of strcasencmp - this was 
something I had planned to do, and even Monty said to change it. About 
'my_global.h' and longlong - I wanted to use this, especially for the 
'rows' issue, but had all sorts of warnings and errors upon adding it 
to dbdimp.h, which seemed to do with issues between perl API and mysql 
API. Did you not have these issues?

Again, thanks so much for your work on this. I do intend to start 
poking at testing this on windows, and will probably be asking you 
questions as I do!

Kind regards,
Patrick
On Apr 28, 2005, at 4:00 AM, Steve Hay wrote:
Hi Patrick,
Patrick Galbraith wrote:
Dear DBI/DBD::mysql developers,
DBD::mysql 2.9007 and 2.9015_3 are now available via CPAN!
Thanks for the new releases!
Please find attached two patches, one for each release.
patch-stable.txt patches 2.9007 to remove all reference to mysql_config
on Win32 where (AFAICT) mysql_config doesn't exist.  If this patch 
looks
good then it would need applying to 2.9015_3 too, of course.  (The 
patch
isn't quite as scary as diff makes it look -- it basically just moves
the two big mysql_config chunks into if (not Win32) { ... } blocks.)

patch-dev.txt patches 2.9015_3 so that it builds on Win32.  This is
largely what I sent you before, but incorporates a couple of further
suggestions that were made at the time, namely: use longlong in
my_global.h instead of long long, and use Perl_ibcmp() instead of
strncasecmp.  This is by no means perfect (pulling in my_global.h
causes a bunch of warnings about macro redefinition clashes with Perl
header files, and there are issues with where Perl_ibcmp() gets the THX
from in threaded perls), but it at least gets things building on Win32
with non-threaded perl, which is all that DBI really supports anyway.
One last thing:  Dare I mention UTF-8 again?  Are there any plans to
have DBD-mysql access MySQL's new character set functionality, or at
least an option to have Perl's utf8 flag set on UTF-8 data?  Rudy did
produce a simplistic patch along the latter lines once, but it never 
got
released.  It would be an extermely useful feature to have.

Cheers,
- Steve

Radan Computational Ltd.
The information contained in this message and any files transmitted 
with it are confidential and intended for the addressee(s) only.  If 
you have received this message in error or there are any problems, 
please notify the sender immediately.  The unauthorized use, 
disclosure, copying or alteration of this message is strictly 
forbidden.  Note that any views or opinions presented in this email 
are solely those of the author and do not necessarily represent those 
of Radan Computational Ltd.  The recipient(s) of this message should 
check it and any attached files for viruses: Radan Computational will 
accept no liability for any damage caused by any virus transmitted by 
this email.
diff -ruN DBD-mysql-2.9015_3.orig/dbdimp.c DBD-mysql-2.9015_3/dbdimp.c
--- DBD-mysql-2.9015_3.orig/dbdimp.c	2005-04-22 05:14:08.0 
+0100
+++ DBD-mysql-2.9015_3/dbdimp.c	2005-04-28 11:37:13.551556400 +0100
@@ -491,7 +491,7 @@
 if (! limit_flag)
 {
   if ((*statement_ptr == 'l' || *statement_ptr == 'L') 
-	  !strncasecmp(statement_ptr+1, imit, 4))
+	  !Perl_ibcmp(pTHX_ statement_ptr+1, imit, 4))
 limit_flag = 1;
 }
 switch (*statement_ptr)
@@ -2103,10 +2103,10 @@
 for ( i = 0; i  statement_length - 1; i++) {
   searchptr= statement[i];
   /* prepared statements for SHOW commands are not supported */
-  if (!strncasecmp(searchptr, SHOW , 5))
+  if (!Perl_ibcmp(pTHX_ searchptr, SHOW , 5))
 imp_sth-use_server_side_prepare = 0;
   /* if there is a 'limit' in the statement... */
-  if (!limit_flag  !strncasecmp(searchptr, limit , 6))
+  if (!limit_flag  !Perl_ibcmp(pTHX_ searchptr, limit , 6))
   {
 limit_flag = 1;
 i += 6;
@@ -2152,7 +2152,7 @@
   */

 /* this is a better way to do this */
-  if ( !strncasecmp(statement, listfields , 11)  
imp_sth-use_server_side_prepare )
+  if ( !Perl_ibcmp(pTHX_ statement, listfields , 11)  
imp_sth-use_server_side_prepare )
   {
 if (dbis-debug = 2)
   PerlIO_printf(DBILOGFP, \listfields\ Statement: %s\n setting 
use_server_side_prepare to 0\n, statement);
@@ -2295,7 +2295,7 @@
 *result= NULL;
   }

-  if (slen = 11  !strncasecmp(sbuf, listfields , 11))
+  if (slen = 11  !Perl_ibcmp(pTHX_ sbuf, listfields , 11))
   {
 /* remove pre-space */
 slen -= 10;
@@ -2703,6 +2703,9 @@
   AV *av;
   MYSQL_ROW cols;
   unsigned long* lengths;
+  int rc;
+  imp_sth_fbh_t * fbh;
+  MYSQL_BIND *bind;
 #if MYSQL_VERSION_ID =SERVER_PREPARE_VERSION
   if (imp_sth-use_server_side_prepare)
@@ -2745,9 +2748,6 @@
   }
 #if MYSQL_VERSION_ID =SERVER_PREPARE_VERSION
-  int rc;
-  imp_sth_fbh_t * fbh;
-  MYSQL_BIND *bind;
   if (imp_sth

Re: DBD::mysql 2.9007 and DBD::mysql 2.9015_3 (beta) released

[Patrick Galbraith]

On Apr 28, 2005, at 9:19 AM, Steve Hay wrote:
Patrick Galbraith wrote:
Steve,

snip
C:\perl5\lib\CORE\win32iop.h(243) : see previous definition of
'tell'
Clearly these need ironing out, but they're better than errors about
Win32 missing long long.
Mine were actually errors  - I'll add the patch and paste the errors. I 
would really like to use my_global.h, as it's definition of longlong 
deals with various OSs and architectures.


Again, thanks so much for your work on this. I do intend to start
poking at testing this on windows, and will probably be asking you
questions as I do!
I'm happy to assist in any way I can.
Btw, did you miss or deliberately duck the charset/UTF-8 question?
Sorry about that! No, I didn't miss your question nor duck it, I was 
replying to you, then got called into a scrum meeting and sent the 
email too soon ;) I was actually going to answer. Yes, we want to 
support UTF-8 - that's one of the feature major bullet-points for 3.0. 
I'm not sure what all is involved, and have to deal with these issues 
in my work on the federated storage engine, but the answer is a 
definite yes ;)


Cheers,
- Steve

Radan Computational Ltd.
The information contained in this message and any files transmitted 
with it are confidential and intended for the addressee(s) only.  If 
you have received this message in error or there are any problems, 
please notify the sender immediately.  The unauthorized use, 
disclosure, copying or alteration of this message is strictly 
forbidden.  Note that any views or opinions presented in this email 
are solely those of the author and do not necessarily represent those 
of Radan Computational Ltd.  The recipient(s) of this message should 
check it and any attached files for viruses: Radan Computational will 
accept no liability for any damage caused by any virus transmitted by 
this email.

Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

DBD::mysql 2.9007 and DBD::mysql 2.9015_3 (beta) released

[Patrick Galbraith]

Dear DBI/DBD::mysql developers,
DBD::mysql 2.9007 and 2.9015_3 are now available via CPAN!
* DBD::mysql 2.9007 is the production release and is available as the  
default version using CPAN shell, or if you go to the CPAN site and  
look up DBD::mysql by module.
* DBD::mysql 2.9015_3 is a beta release, which includes server-side  
prepared statement and MySQL Embedded Server support, and is available  
on CPAN at  
http://www.cpan.org/modules/by-module/DBD/CAPTTOFU/DBD-mysql 
-2.9015_3.tar.gz

The latest changes are:
2.9007
 * Fix to Statement.pm for old API call for numfields that caused
warnings on 40numrows and akmisc tests
 * Fix to warning - t/40listfields to check logic properly
 * Fix to bind_ph to throw an error if trying to bind a non-numeric
value as numeric
 * Better fix for dealing with error condition in $sth-rows()
2.9015_3
* Added patch from Stas Beckman for new DBI feature take_imp_data,  
needed
   for DBI::Pool
* Fix to Statement.pm for old API call for numfields that caused
  warnings on 40numrows and akmisc tests
* Fix to bind_ph to throw an error if trying to bind a non-numeric
   value as numeric
* Better fix for dealing with error condition in $sth-rows()
* Fix to bind_param to throw error when trying to bind a non-numeric as
   numeric

About server-side prepare statement and embedded support (nutshell  
descriptions):

To enable server-side prepare, one has to simply build DBD::mysql using  
perl Makefile.PL --ps-protocol and in your code, you simply turn it  
on by appending ;mysql_server_prepare=1 in your DSN (Data Source  
Name) value in connect.

For embedded perl Makefile.PL --force-embedded, and in your code, use  
a DSN of  
'$testdsn=DBI:mysqlEmb:database=test;mysql_embedded_options=--help,-- 
verbose;

These of course are very brief descriptions on how to use both of these  
new features, but please refer to the perldoc documentation with  
2.9015_3 for a more thorough description.

Please feel free to use this list to post any questions you may have,  
and please enjoy using DBD::mysql!

Kind regards,
Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever  
standards he sets by exemplary acts, all the world pursues  --  
Bhagavad Gita

Re: Problem with bind_param using DBD::mysql

[Patrick Galbraith]

Steve,
What compiler have you used? For the server, we don't use Cygwin for 
our official binaries, so I'm wondering if there are any issues in 
using Cygwin vs. MSVC++ (or whatever) to compile DBD::mysql.

thanks!
Patrick
On Apr 7, 2005, at 1:07 AM, Steve Hay wrote:
Ron Savage wrote:
On Wed, 6 Apr 2005 09:33:36 -0700, Patrick Galbraith wrote:
Hi Folks

Thanks so much for your patch! I do need to check out windows
issues. I didn't realise that windows doesn't have LONG LONG. If
possible, I'd like to pick your brain about getting a setup to
compile on windows. I'll talk to the dev team about how to deal

What exactly does it take to compile DBD::mysql under Windows?
I run Windows (usually).
Perl, MySQL and a C compiler.
I usually hack out the stuff in the Makefile.PL that refers to
mysql_config (which doesn't exist on Win32) and then just run:
perl Makefile.PL --cflags=-IC:/mysql/include
--libs=C:/mysql/lib/mysqlclient.lib --testuser=root
(Leaving the mysql_config stuff in doesn't hurt, other than to spew out
half a dozen errors about it not being recognized as an internal or
external command, operable program or batch file.)
- Steve

Radan Computational Ltd.
The information contained in this message and any files transmitted 
with it are confidential and intended for the addressee(s) only.  If 
you have received this message in error or there are any problems, 
please notify the sender immediately.  The unauthorized use, 
disclosure, copying or alteration of this message is strictly 
forbidden.  Note that any views or opinions presented in this email 
are solely those of the author and do not necessarily represent those 
of Radan Computational Ltd.  The recipient(s) of this message should 
check it and any attached files for viruses: Radan Computational will 
accept no liability for any damage caused by any virus transmitted by 
this email.

Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Re: Problem with bind_param using DBD::mysql

[Patrick Galbraith]

Steve,
Thanks so much for your patch! I do need to check out windows issues. I  
didn't realise that windows doesn't have LONG LONG. If possible, I'd  
like to pick your brain about getting a setup to compile on windows.  
I'll talk to the dev team about how to deal with unix calls that aren't  
implemented for windows. The one particular call, strcasencmp, is  
case-insensitive, so it could be LIMIT or limit, which would fail.  
Also, you might've found a bug with how I check to see if the  
my_ulonglong returned from mysql_affected_rows is -1 (error).

Again,
thank you,
Patrick
On Apr 6, 2005, at 2:41 AM, Steve Hay wrote:
Patrick Galbraith wrote:
On Apr 5, 2005, at 3:01 PM, Tim Bunce wrote:

On Tue, Apr 05, 2005 at 11:46:21AM -0700, Patrick Galbraith wrote:

Steve,
There is a version of DBD::mysql (2.9015) that does support
placeholders in the server, via CVS (or I can package it  and send  
it
to you). I would be glad to give you a version of it to try out,  
and I
think it may deal with your problem better than the current driver
(which emulates it) the new driver uses the database to handle
placeholders. I have tested this code on numerous SQL statements  
with
placeholders, and it works great.


That's great. But the behavior when placeholders are emulated[1]
still could be easily improved with a one-line code change.

Tim,
I'll fix this ;)

Tim.
[1] I'm presuming that the latest version still lets you use
emulated placeholders either optionally or when talking to old
servers. Is that right?

Yes, if the version of mysql is less than 4.1.3, it doesn't even
compile in server-side-prepare. With a server  4.1.3,  one sets
'mysql_server_prepare=1'  in the DSN to enable it, and without it, it
defaults to old behaviour.
Is the looks_like_number() issue solved already in the dev version?
I just checked out the Dev-2_9 branch.  It took a bit of hacking around
to get it to build on Win32, and even then a load of tests failed, but
when I re-tried the sample program that I posted previously it worked
fine even without mysql_server_prepare=1 in the DSN.  trace() shows
that the SQL statement now contains 1 rather than 1.#INF or '1.#INF':
UPDATE foo SET str = 'one', num = 1 WHERE id = 1
Is this what you expected?
Trying again with mysql_server_prepare=1 in the DSN, the program now
says UPDATE affected 25388176 rows (!), but actually didn't change  
any
rows.  This is presumably not what you expected, but may very well be
due to the crude hacking that I did to make it build.

Do you have a Win32 environment that you could try this out on?
If not, here are the issues that I encountered:
- long long and uint are unknown; I used LONGLONG and UINT instead;
- strncasecmp is unknown; I used strncmp instead;
- dbdimp.h line 257 has a syntax error;
- dbdimp.c contains declarations after code at line 2823.
Attached is a patch of the changes that I made.
The test failures were as follows:
C:\Temp\modules\DBD-mysqlnmake test
Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
C:\perl5\bin\perl.exe -MExtUtils::Command::MM -e
test_harness(0, 'b
lib\lib', 'blib\arch') t/*.t
t/00base...ok
t/10dsnlistok
t/20createdrop.ok
t/30insertfetchok
t/35limit..DBD::mysql::st execute failed: You have an error in
your SQL
syntax; check the manual that corresponds to your MySQL server version
for the r
ight syntax to use near ''20', '50'' at line 1 at t/35limit.t line 106.
DBD::mysql::st fetchall_arrayref failed: fetch() without execute() at
t/35limit.
t line 110.
t/35limit..FAILED tests 107-109
Failed 3/113 tests, 97.35% okay
t/35prepareok
t/40bindparam..ok
t/40blobs..ok
t/40listfields.Use of uninitialized value in numeric eq (==) at
t/40listfiel
ds.t line 132.
t/40listfields.ok
t/40nulls..ok
t/40numrowsok
t/50chopblanks.ok
t/50commit.ok
t/60leaks..skipped
all skipped: $ENV{SLOW_TESTS} is not set or Proc::ProcessTable
not insta
lled
t/ak-dbd...ok 12/90DBD::mysql::st execute failed: You have an
error in y
our SQL syntax; check the manual that corresponds to your MySQL server
version f
or the right syntax to use near 'LISTFIELDS testae' at line 1 at
t/ak-dbd.t line
 143.
t/ak-dbd...FAILED test 13
Failed 1/90 tests, 98.89% okay
t/akmisc...ok 56/351DBD::mysql::st execute failed: You have an
error in
your SQL syntax; check the manual that corresponds to your MySQL server
version
for the right syntax to use near 'LISTFIELDS testae' at line 1 at
C:\Temp\module
s\DBD-mysql\blib\lib/Mysql.pm line 175.
Can't call method name on an undefined value at t/akmisc.t line 660.
t/akmisc...dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 73-351
Failed 279/351 tests, 20.51% okay
t/dbdadmin.ok
t/insertid.ok
t/mysqlDBD::mysql::st execute failed: Table 'table01

Re: Problem with bind_param using DBD::mysql

[Patrick Galbraith]

Steve,
There is a version of DBD::mysql (2.9015) that does support 
placeholders in the server, via CVS (or I can package it  and send it 
to you). I would be glad to give you a version of it to try out, and I 
think it may deal with your problem better than the current driver 
(which emulates it) the new driver uses the database to handle 
placeholders. I have tested this code on numerous SQL statements with 
placeholders, and it works great.

Just let me know if you'd be interested,
Kind regards,
Patrick
On Apr 5, 2005, at 2:23 AM, Tim Bunce wrote:

Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Re: Problem with bind_param using DBD::mysql

[Patrick Galbraith]

On Apr 5, 2005, at 3:01 PM, Tim Bunce wrote:
On Tue, Apr 05, 2005 at 11:46:21AM -0700, Patrick Galbraith wrote:
Steve,
There is a version of DBD::mysql (2.9015) that does support
placeholders in the server, via CVS (or I can package it  and send it
to you). I would be glad to give you a version of it to try out, and I
think it may deal with your problem better than the current driver
(which emulates it) the new driver uses the database to handle
placeholders. I have tested this code on numerous SQL statements with
placeholders, and it works great.
That's great. But the behavior when placeholders are emulated[1]
still could be easily improved with a one-line code change.
Tim,
I'll fix this ;)
Tim.
[1] I'm presuming that the latest version still lets you use
emulated placeholders either optionally or when talking to old
servers. Is that right?
Yes, if the version of mysql is less than 4.1.3, it doesn't even 
compile in server-side-prepare. With a server  4.1.3,  one sets  
'mysql_server_prepare=1'  in the DSN to enable it, and without it, it 
defaults to old behaviour.

Kind regards,
Patrick

Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Re: Announcement: prepared statement and embedded server support on Dev-2_9 CVS

[Patrick Galbraith]

Guiseppe,
I have today committed the missing Makefile.PL.embedded today in CVS,
Thank you for your email!
regards,
Patrick
On Sep 6, 2004, at 4:15 AM, Giuseppe Maxia wrote:
Hi, Patrick,
thanks for making these changes, which were really needed.
I tested both the prepared statements and the support for LIMIT.
I could not test the embedded engine, though, because the Makemaker 
script can't find a component.

#  error reported when --embedded and --force-embedded are used
Unable to copy Makefile.PL.embedded to mysqlEmb/Makefile.PL
I would like to make an announcement with some tests on Perlmonks 
(http://www.perlmonks.org), so I would appreciate if I could get the 
missing piece.

Thanks
All the best
Giuseppe
Patrick Galbraith wrote:
Hello Users/Developers,
I have just committed support for prepared statements and MySQL  
embedded server support to CVS development branch Dev-2_9 (based off 
of  2.900x code) for DBD::mysql. You can get this code to try out 
via:
[SNIP]
--
     _ _   _
 / _  |\( ( \ / )
( (_| | | | / ___ |) X (
 \___ |_|_|_\_(_/ \_)
(_|
Sapere, saper fare, fare, far sapere
http://gmax.oltrelinux.com
Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Re: Announcement: prepared statement and embedded server support on Dev-2_9 CVS

[Patrick Galbraith]

Darren,
Eventually, we could possibly have a method to detect version
the best way I know of to get mysql version is in an SQL call via DBD:
show global variables like 'version' in the database, or
$database_version = $dbh-get_info(18) (more info on this in 'perldoc 
DBI')

The version that supports server prepare is 4.1.1 and above.
As far as making server side prepare default, a lot of developers don't 
want this behaviour and the maintainer, Rudy Lippan doesn't want this 
as well, so we leave it optional.

Hope this answers your question(s),
regards,
Patrick
On Sep 4, 2004, at 11:24 AM, Darren Duncan wrote:
Hello Patrick,
Is it possible for you to automatically detect what version of the 
MySQL database server or embedded version you have, and then just 
automatically use server-side prepared statements if the version 
supports them?  I think this would be the best option.  If you wanted 
to give people something to customize, you could give a switch to 
force client-side handling, like was used before.  But people who 
don't say that simply get the best available option.

Also, since I'm writing you anyway, can you please tell me if there is 
a quick and simple way for me as a DBI user to query for what MySQL 
version I am connected to, so my code can automatically make use of 
newer features when possible (eg: subqueries), or emulate them for 
older versions?

Please reply asap.
Thank you very much. -- Darren Duncan
Hello Users/Developers,
I have just committed support for prepared statements and MySQL 
embedded server support to CVS development branch Dev-2_9 (based off 
of  2.900x code) for DBD::mysql. You can get this code to try out 
via:

cvs -d :pserver:[EMAIL PROTECTED]:/cvs/public login
cvs -d :pserver:[EMAIL PROTECTED]:/cvs/public co -rDev-2_9 
modules/DBD-mysql

To use server side prepare statements, all you really need to do is 
set  the value mysql_server_prepare in the connect string:

my $dbh =  DBI-connect(DBI:mysql:database=test;host=localhost: 
mysql_server_prepare=1, ,);

When you build DBD::mysql and run make test, after you first test 
without server side prepare statements, you can test with by 
exporting  the environment variable MYSQL_SERVER_PREPARE

export MYSQL_SERVER_PREPARE=1
and then run 'make test' again. This stage will be improved in the  
future.

Also, for information about using the embedded server, please read 
the  pod documentation found in the perl module itself.

For more information about prepared statements and how you can take 
advantage of them, please feel free to read my OSCON presentation:

http://patg.net/DBD.pdf
Kind regards,
Patrick Galbraith
Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Re: Installing DBD::mysql on Mac OS X 10.3.5

[Patrick Galbraith]

The latests Dev-2_9 branch in CVS fixes the Mac OS X issue as well, if 
you want to try out this version (prepared statements and embedded code 
included)

regards,
Patrick
On Sep 5, 2004, at 12:08 PM, Joris Verboomen wrote:
That worked.  I first tried going back to 4.1.3 but that didn't change 
anything, then to 4.0.20 and that worked although I had to force the 
install:

Failed 1/18 test scripts, 94.44% okay. 3/767 subtests failed, 99.61% 
okay.
make: *** [test_dynamic] Error 2

After doing this I removed MySQL 4.0.20 again, re-installed 5.0.0 and 
imported my database.  It still seems to working fine, at least for 
what I am using it for.

Thanks, Joris.
Remo Sanges wrote:
On Sep 5, 2004, at 4:22 PM, Joris Verboomen wrote:
When I try to install Bundle::Mysql or Bundle::DBD::mysql using CPAN 
I get exactly the same error.  The second reply to edit Config.pm 
and put the correct line:

ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc'
in there is no longer required because that has already been done.  
So still stuck ?

If you get the same error using
install Msql-Mysql-modules-1.2219,
which is an error on a test that try to shut down
your mysql server, it can depends on the fact
that you are running mysql 5.0 which is an alpha
release
Try to install a standard edition
http://dev.mysql.com/downloads/mysql/4.0.html
and see if you get the same errors installing
the modules
HTH
Remo

Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Re: install perl DBD::mysql problem on linux

[Patrick Galbraith]

Zhiliang,
I'll see if I have a server with that version of RH installed and see 
what I can come up with,

thank you,
regards,
Patrick
On Sep 2, 2004, at 10:51 AM, Zhiliang Hu wrote:
I have following problem when tried to install perl DBD::mysql (on a 
Red Hat Linux AS server 3.2.3-34, a dual-processor machine):

Multiple lines of
Unsuccessful stat on filename containing newline at 
/usr/lib/perl5/5.8.0/ExtUtils/Liblist/Kid.pm line 97.

at the perl Makefile.PL step (perl -MCPAN -e shell got the same).
I saw this problem was posted on this forum by
Pyro3k (bbs3k_at_hotmail.com) before but don't see any 
replies/solutions to it.  Any hint will be appreciated!

Zhiliang
Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Re: DBD::mysql and mysql_use_result

[Patrick Galbraith]

On Aug 9, 2004, at 8:01 PM, Rudy Lippan wrote:
On Sat, 7 Aug 2004, Patrick Galbraith wrote:
As far as use_result vs. store result, the server prepared statements
(mysql 4.1 and greater) will always use 'store result', as this has no
affect on performance as per the API documentation.
I plan, if possible, to make use result the default with prepared 
statements,
my thinking here is this: if you are going to be using parepared 
statements, you
will more than likly be running in a persistant envionment, in which 
case,
memory usage becomes more of an issue. esp. in something like a 
mod_perl
envionment because when you use store result you will more than 
likely use 2x
the memory (or more) -- Think of an application that munges the result 
result
set and pases the munged data off to a templating system for a total 
of three
times memory usage of just the result set.

Rudy,
Hmm... I can see that point. Is there something similar to this in 
other database drivers? What setting do they default to? I would like 
to bring this up too with the fellow who implemented the server prepare 
statements in the server and see what he thinks.


And from my reading of the docs (though I have not had a chance to 
test this
yet), mysql_stmt_store_result() need not be called mysql_stmt_fetch(). 
Is this
the case?

Yes, an I just tested this with the latest code I've worked on, and it 
works without store_result. I'm curious to see what my benchmarking 
will show ;)

As far as the question about use_result, I'll have to test this.
regards,
Patrick

Rudy
--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Re: Drivers that support server-prepare-statements?

[Patrick Galbraith]

Mike,
No difference at all. I've simply implemented dbh-prepare to use the 
server to prepare and sql statement (which is now supported in mysql 
4.1.3) as opposed to the driver emulating a server prepare. Nothing 
that a DBI developer has to worry about from a high level of using 
$dbh-prepare.

regards,
Patrick
On Jul 26, 2004, at 10:52 AM, Mike Schienle wrote:
On Mon, July 26, 2004 12:19 pm, Patrick Galbraith said:
Jeff Zucker wrote:
Patrick Galbraith wrote:
Hi all,
I'm working on my OSCON presentation, and was hoping to get a list 
of
DBD drivers that currently support server prepare statements?

The various SQL::Statement drivers (DBD::CSV, DBD::DBM, DBD::AnyData,
DBD::Excel, etc.), support server (in as much as there is one) 
prepare
statements in the sense that there can be significant performance
gains from a prepare-once-execute-many strategy and an additional
performance gain from using placeholders.
I'm finding anywhere from 30-60% gain ;)
I'm confused (shocking, I know). How does Patrick's server prepare 
differ from
$dbh-prepare and $sth-execute? I'm used to seeing a much higher 
increase
with prepare/execute vs. do, so obviously we're talking about 
something else
that I'm completely unaware of.

--
Mike Schienle

Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Re: DBD::mysql and mysql_use_result

[Patrick Galbraith]

On Aug 6, 2004, at 9:19 AM, Alan Burlison wrote:
Alexey Stroganov wrote:
It was already implemented in my tree with the same behaviour as for 
'mysql_server_prepare' attribute:
 - attribute 'mysql_use_result' on dbh level, this allows to
   enable/disable mode for all new statements:
 - DBI-connect(DBI:mysql:test;mysql_use_result=1, root, );
 - $dbh-{'mysql_use_result'}=0; #disable
   $dbh-{'mysql_use_result'}=1; #enable
 When new sth is created we set default value of attribute  
'mysql_use_result' from $dbh. One can override the default  
value:
 - $sth=$dbh-prepare(statement, {'mysql_use_result' = 1});
 - $sth-{'mysql_use_result'}=0; #disable
   $sth-{'mysql_use_result'}=1; #enable
Oooh, I'd *love* a copy, pretty please ;-)
What does 'mysql_server_prepare' do BTW, I can't find it in the docs?
It's not public yet, and therefore not documented as such, but 
mysql_server_prepare enables the server to prepare the statement as 
opposed to emulating the prepare in the driver. Prior to mysql 4.1, 
there was no support for server prepare statements, so it was up to the 
driver to parse placeholders and then substitute values upon execution. 
The current DBD::mysql that is public does this. With the latest 
changes, the server will prepare the statement. This can bring some 
performance increase, especially if you are dealing with a lot of 
inserts.

As far as use_result vs. store result, the server prepared statements 
(mysql 4.1 and greater) will always use 'store result', as this has no 
affect on performance as per the API documentation.

I will make my OSCON slides public which explain how this works, and 
also be glad to answer anyone's questions about this.

regards
Patrick
--
Alan Burlison
--
Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Re: DBD::mysql and mysql_use_result

[Patrick Galbraith]

Alan,
The macro is D_imp_dbh_from_sth,
regards,
Patrick
On Aug 6, 2004, at 5:51 AM, Jochen Wiedmann wrote:
Alan Burlison wrote:
One other question - how do I get the parent DBH from a STH from 
within the XS code for a DBD driver?

There's a DBI macro for that, I do not remember the name, but most 
probably its DBIxxx_parent or similar.

Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Re: DBD::mysql and mysql_use_result

[Patrick Galbraith]

Tim,
It won't. We will work with the maintainer to ensure that CPAN and 
mysql.com's source is the same. No matter how we internally manage 
DBD::mysql code internally, we will go through CPAN/cvs to merge our 
work.

regards,
Patrick
On Aug 7, 2004, at 12:54 PM, Tim Bunce wrote:
On Fri, Aug 06, 2004 at 07:39:11PM +0300, Alexey Stroganov wrote:
It was already implemented in my tree with the same behaviour as for
'mysql_server_prepare' attribute:
How are you intending to ensure that the DBD::mysql source at mysql.com
doesn not diverge from that on CPAN?
Tim.
Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Re: DBI BOF @ OSCON ?

[Patrick Galbraith]

On Jul 26, 2004, at 11:20 PM, Tim Bunce wrote:
On Mon, Jul 26, 2004 at 09:32:45AM -0700, Patrick Galbraith wrote:
Tim,
What's the status of the work?
Is a patch available for Rudy to integrate?
It's complete. I can run all tests using server prepare vs. emulated 
in
the driver, and all pass. I've done benchmarking with my own script 
and
found using the server is of course faster than emulation in the 
driver.
Yes, I do have a patch for Rudy, but he's on vacation right now (and
I've been communicating with him all along the work that I'm doing). 
As
well, bind_param now uses the server as well, as opposed to 
emulation
in the driver, as well as various code cleanups. In early March, Monty
went through the code with me and found various algorithms and logic
that could be reduced, cleaned up cruft, etc.
Great. Is the behaviour user selectable - so applications can opt
to use the old emulated behaviour if they want to?
Tim,
Yes ;) ... And there are some cases where one might want to do so.
Regards,
Patrick



As well, I wouldn't mind also discussing DBI sometime with a group 
of
people, if anything has happened to organise a BOF or even an 
informal
get-together? I've been so involved in the lower level part of the 
driver
that I wouldn't mind discussing in a group what is in store for DBI
development and how it might affect other drivers.
I announced the DBI Driver Developers BoF on [EMAIL PROTECTED] last 
week:

http://conferences.oreillynet.com/cs/os2004/view/e_sess/5782
As someone working on a DBI driver you ought to be subscribed to 
that list.
I am, and replied to that email last night ;) Also, I have even 
recently
replied to a gentleman from Novell about support on Netware (I was
recently working with the  build team for the server on various builds
for different platforms, and Netware was one of the ones that we 
worked
on making available, so DBD support would only follow).
Great. Thanks Patrick.

Tim.
Thanks much,
Patrick

Tim.

--
Patrick Galbraith, Senior Systems Engineer
MySQL AB, www.mysql.com
Office: +1 206 719 2461
Are you MySQL certified?  www.mysql.com/certification

Patrick Galbraith Senior Software Developer
[EMAIL PROTECTED] http://www.mysql.com
Whatever action a great man performs, common men follow. Whatever 
standards he sets by exemplary acts, all the world pursues  -- 
Bhagavad Gita

Re: DBI BOF @ OSCON ?

[Patrick Galbraith]

Hi all,
I will be giving a presentation on DBD::mysql on Wednesday, 7/28:
- Conference Session
 Session ID: 5485
 Title: How DBD::mysql Enhancements Can Benefit the Perl Developer
 Date: 07/28/2004
 Time: 2:35pm to 3:20pm
 Location: Salon D
I'll be covering my work on server side prepared statement implementation that I've 
implemented recently, and how it can benefit developers. I have some good numbers to 
show this implementation can gain  the developer some speed! ;)
As well, I wouldn't mind also discussing DBI sometime with a group of people, if 
anything has happened to organise a BOF or even an informal get-together? I've been so 
involved in the lower level part of the driver that I wouldn't mind discussing in a 
group what is in store for DBI development and how it might affect other drivers.
regards,
Patrick

Dean Arnold wrote:
Tim Bunce wrote:
On Wed, Apr 30, 2003 at 09:00:54PM -0700, Dean Arnold wrote:
Tried this once before, but couldn't make it...

Me too :)  I couldn't make last year's conference but I'm all booked
up to be there this year.
Anyone fancy organizing a DBI BOF @ OSCON this year?
Tim.

Alas, I'm buried under other commitments, and have a major
conference in October I need to spend all my $$$ on, so I'm
afraid I'm unable to host this year.
I'm still considering taking a break from the laptop
that week and heading up for some camping, so if you
(and Jeff Z. too) are around, I may try talking you into
a meal and some brews (at my expense), but even thats
looking pretty shaky right now.
Have fun in Portland, I hope the weather is as fine
as it was last year (and that O'Reilly sprung for some
bigger conference rooms!)
Dean Arnold
Presicient Corp.

--
Patrick Galbraith, Senior Systems Engineer 
MySQL AB, www.mysql.com
Office: +1 206 719 2461 

Are you MySQL certified?  www.mysql.com/certification

Drivers that support server-prepare-statements?

[Patrick Galbraith]

Hi all,
I'm working on my OSCON presentation, and was hoping to get a list of 
DBD drivers that currently support server prepare statements?

Does anyone know if such a list (authoritative list) exists?
thanks in advance,
Patrick
--
Patrick Galbraith, Senior Systems Engineer 
MySQL AB, www.mysql.com
Office: +1 206 719 2461 

Are you MySQL certified?  www.mysql.com/certification

Re: DBI BOF @ OSCON ?

[Patrick Galbraith]

Tim,
What's the status of the work?
Is a patch available for Rudy to integrate?
 

It's complete. I can run all tests using server prepare vs. emulated in 
the driver, and all pass. I've done benchmarking with my own script and 
found using the server is of course faster than emulation in the driver.
Yes, I do have a patch for Rudy, but he's on vacation right now (and 
I've been communicating with him all along the work that I'm doing). As 
well, bind_param now uses the server as well, as opposed to emulation 
in the driver, as well as various code cleanups. In early March, Monty 
went through the code with me and found various algorithms and logic 
that could be reduced, cleaned up cruft, etc.

 

As well, I wouldn't mind also discussing DBI sometime with a group of 
people, if anything has happened to organise a BOF or even an informal 
get-together? I've been so involved in the lower level part of the driver 
that I wouldn't mind discussing in a group what is in store for DBI 
development and how it might affect other drivers.
   

I announced the DBI Driver Developers BoF on [EMAIL PROTECTED] last week:
 http://conferences.oreillynet.com/cs/os2004/view/e_sess/5782
As someone working on a DBI driver you ought to be subscribed to that list.
I am, and replied to that email last night ;) Also, I have even recently 
replied to a gentleman from Novell about support on Netware (I was 
recently working with the  build team for the server on various builds 
for different platforms, and Netware was one of the ones that we worked 
on making available, so DBD support would only follow).

Thanks much,
Patrick

Tim.
 

--
Patrick Galbraith, Senior Systems Engineer 
MySQL AB, www.mysql.com
Office: +1 206 719 2461 

Are you MySQL certified?  www.mysql.com/certification

Re: Drivers that support server-prepare-statements?

[Patrick Galbraith]

So, Tim is going to be there after all? For some reason, I thought that 
he wasn't able to make it this year. I have been so busy, that I 
probably missed some of the emails.

Jeff Zucker wrote:
Patrick Galbraith wrote:
Hi all,
I'm working on my OSCON presentation, and was hoping to get a list of 
DBD drivers that currently support server prepare statements?

The various SQL::Statement drivers (DBD::CSV, DBD::DBM, DBD::AnyData, 
DBD::Excel, etc.), support server (in as much as there is one) prepare 
statements in the sense that there can be significant performance 
gains from a prepare-once-execute-many strategy and an additional 
performance gain from using placeholders. 
I'm finding anywhere from 30-60% gain ;)

At OSCON there are DBI BOF's on Tuesday and Thursday, and Tim's giving 
an Any Questions talk.  I'm looking forward to meeting you there.

--
Patrick Galbraith, Senior Systems Engineer 
MySQL AB, www.mysql.com
Office: +1 206 719 2461 

Are you MySQL certified?  www.mysql.com/certification

Re: Fix for problems installing DBD::mysql-2.9004 with mysql-4.0.20

[Patrick Galbraith]

Steven,
which OS, version is this?
I'd be glad to test this out and find out what the fix is. Did you get 
DBD::mysql from cpan?

thanks much!
Patrick
Steven Lembark wrote:
Perl-5.8.5 compiled happily, now updating DBD::mysql with:
mysql-standard-4.0.20-pc-linux-i686
DBD-mysql-2.9004
Catch is that newer mysql distro's use ./lib and ./include for
their files not ./lib/mysql or ./include/mysql. Fix is to symlink
'.' to mysql in the lib directory and use an explicit '-I' with
the cflags.
For example:
$ perl Makefile.PL
I will use the following settings for compiling and testing:
 cflags(mysql_config) = -I/usr/local/mysql/include/mysql 
-mcpu=pentiumpro
 libs  (mysql_config) = -L/usr/local/mysql/lib/mysql 
-lmysqlclient -lz -lcrypt -lnsl -lm -lc -lnss_files -lnss_dns -lresolv 
-lc -lnss_files -lnss_dns -lresolv
 nocatchstderr (default ) = 0
 nofoundrows   (default ) = 0
 ssl   (guessed ) = 0
 testdb(default ) = test
 testhost  (default ) =
 testpassword  (default ) =
 testuser  (default ) =

To change these settings, see 'perl Makefile.PL --help' and
'perldoc INSTALL'.
Note (probably harmless): No library found for -lmysqlclient
Using DBI 1.43 (for perl 5.008005 on i686-linux-thread-multi) installed 
in /opt/perl/5.8/lib/site_perl/5.8.4/i686-linux-thread-multi/auto/DBI
Writing Makefile for DBD::mysql

EH??? No libmysqlclient?
$ find /usr/local/mysql/ -name 'libmysqlclient*' -follow
/usr/local/mysql/lib/libmysqlclient.a
/usr/local/mysql/lib/libmysqlclient_r.a
One hak fixes it:
cd /usr/local/mysql/lib;
ln -fs . mysql;
Now I get:
cp lib/DBD/mysql.pm blib/lib/DBD/mysql.pm
cp lib/DBD/mysql/GetInfo.pm blib/lib/DBD/mysql/GetInfo.pm
cp lib/Mysql.pm blib/lib/Mysql.pm
cp lib/DBD/mysql/INSTALL.pod blib/lib/DBD/mysql/INSTALL.pod
cp lib/Mysql/Statement.pm blib/lib/Mysql/Statement.pm
cp lib/Bundle/DBD/mysql.pm blib/lib/Bundle/DBD/mysql.pm
/opt/gcc/bin/gcc -c 
-I/opt/perl/5.8/lib/site_perl/5.8.4/i686-linux-thread-multi/auto/DBI 
-I/usr/local/mysql/include/mys
ql -mcpu=pentiumpro -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS 
-fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FIL
E_OFFSET_BITS=64 -I/usr/include/gdbm -O3 -march=pentium4 
-DVERSION=\2.9004\ -DXS_VERSION=\2.9004\ -fpic -I/opt/pe
rl/5.8/lib/5.8.5/i686-linux-thread-multi/CORE   dbdimp.c
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
In file included from dbdimp.c:19:
dbdimp.h:21:49: mysql.h: No such file or directory
dbdimp.h:22:49: errmsg.h: No such file or directory
In file included from dbdimp.c:19:
dbdimp.h:106: error: parse error before MYSQL
dbdimp.h:106: warning: no semicolon at end of struct or union
dbdimp.h:117: error: parse error before '}' token
dbdimp.h:146: error: parse error before MYSQL_RES
dbdimp.h:146: warning: no semicolon at end of struct or union
dbdimp.h:159: error: parse error before '}' token
In file included from dbdimp.c:19:
snip


Which was fixed via:
perl Makefile.PL  --cflags='-O3 -march=i686 
-I/usr/local/mysql/include';

--
Patrick Galbraith, Senior Systems Engineer
MySQL AB, www.mysql.com
Office: +1 206 719 2461
Are you MySQL certified?  www.mysql.com/certification