Skip Menu |
 

This queue is for tickets about the Class-DBI CPAN distribution.

Report information
The Basics
Id: 34885
Status: open
Priority: 0/
Queue: Class-DBI

People
Owner: Nobody in particular
Requestors: fenlisesi [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: v3.0.17
Fixed in: (no value)



Subject: (int4) bind type picked for varchar column.
Download (untitled) / with headers
text/plain 1.5k
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 =)
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>
Download (untitled) / with headers
text/plain 572b
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
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>
Download (untitled) / with headers
text/plain 1.2k
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.
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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.