Bug #34885 for Class-DBI: (int4) bind type picked for varchar column.

Fri Apr 11 13:28:00 2008 fenlisesi [...] gmail.com - Ticket created

Subject:

(int4) bind type picked for varchar column.

I would like to call your attention to http://rt.cpan.org/Public/Bug/Display.html?id=34840 There seems to be some possibility that the problem described in that ticket is actually caused by a Class::DBI (or a Class::DBI::Sweet) bug. The problem appears to get "fixed" by unconditionally and immediately returning from _bind_param() in Class::DBI, leaving bind types 'unknown'. Since the very similar COUNT query works and exactly two consecutive bind params in the failing query are assigned type (int4) (as opposed to all bind types left (unknown) for the COUNT query), I can surmise that the (int4) bind type assignments are intended for the LIMIT and OFFSET values, but that somehow, Class::DBI (or whoever else it may be that is making that call) mixes up the order of the bind params (or the total number of them), assigning bind type (int4) to params #5 and #6, instead of the intended #9 and #10, the LIMIT and OFFSET integers. If this does not look like a bug (and is perhaps due to misuse of Class::DBI), or it is difficult to fix, I would like to hear what you guys think about the return-from-_bind_param()-right-away workaround. Could that cause problems in some cases, or is it only a hopefully tolerable inefficiency? If you are interested, I will try to reduce the problem to a small test script and test database, but that will probably take me at least half a day. I am therefore hoping that you will say that the workaround is fine or that you know exactly what this is about and tell me how I can magically fix it at once =)

Sun Apr 13 00:29:48 2008 tony [...] tmtm.com - Correspondence added

Subject:	Re: [rt.cpan.org #34885] (int4) bind type picked for varchar column.
Date:	Sun, 13 Apr 2008 13:29:35 +0900
To:	bug-Class-DBI [...] rt.cpan.org
From:	"Tony Bowden" <tony [...] tmtm.com>

Show quoted text

> If you are interested, I will try to reduce the problem to a small > test script and test database, but that will probably take me at least > half a day. I am therefore hoping that you will say that the > workaround is fine or that you know exactly what this is about and > tell me how I can magically fix it at once =)

I have no idea what the problem is, where it comes from, or how to properly fix it. If you're going to put a test case together, it would be very handy if you could isolate it to Class::DBI itself rather than Class::DBI::Sweet. Thanks, Tony

Sun Apr 13 00:29:49 2008 The RT System itself - Status changed from 'new' to 'open'

Sun Apr 13 11:10:12 2008 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #34885] (int4) bind type picked for varchar column.
Date:	Sun, 13 Apr 2008 16:09:28 +0100
To:	bug-Class-DBI [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

tony@tmtm.com via RT wrote: Show quoted text

> Queue: Class-DBI > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=34885 > >

>> If you are interested, I will try to reduce the problem to a small >> test script and test database, but that will probably take me at least >> half a day. I am therefore hoping that you will say that the >> workaround is fine or that you know exactly what this is about and >> tell me how I can magically fix it at once =)

> > I have no idea what the problem is, where it comes from, or how to > properly fix it. If you're going to put a test case together, it would > be very handy if you could isolate it to Class::DBI itself rather than > Class::DBI::Sweet.

I recall experiencing a similar problem in the past. DBD::mysql was passing a string into the bind as a number. It turns out what happened was my code was accidentally using the string as a number (with the appropriate warning) which caused the underlying SV to have an IV component. DBD::mysql saw that and figured it was a number. So look to see if anything is warning about using a string as a number. -- s7ank: i want to be one of those guys that types "s/j&jd//.^$ueu*///djsls/sm." and it's a perl script that turns dog crap into gold.

Tue Apr 15 14:55:30 2008 fenlisesi [...] gmail.com - Correspondence added

From:

fenlisesi [...] gmail.com

On Sun Apr 13 00:29:48 2008, tony@tmtm.com wrote: Show quoted text

> > If you are interested, I will try to reduce the problem to a small > > test script and test database, but that will probably take me at least > > half a day. I am therefore hoping that you will say that the > > workaround is fine or that you know exactly what this is about and > > tell me how I can magically fix it at once =)

> > I have no idea what the problem is, where it comes from, or how to > properly fix it. If you're going to put a test case together, it would > be very handy if you could isolate it to Class::DBI itself rather than > Class::DBI::Sweet. > > Thanks, > > Tony

Tony, you are absolutely right, I provided little clue. Thank you and Schwern for taking a look at it. I tried to create the problem using Class::DBI::AbstractSearch, but I was not able to (The query worked without a problem when I used Class::DBI with AbstractSearch). I provided some more data (and a test script) in RT#35085: http://rt.cpan.org/Public/Bug/Display.html?id=35085 but that involves Class::DBI::Sweet.