Possible strange problem in DBI::type_info()
Hi all,
I found a strange problem in DBI::type_info().
I don't know much of DBI internals. Only found that sometimes,
the 'type_info_all' structure returned by the driver is
mangled by some shift() that happens in DBI::type_info().
This happens only for DBD::Informix driver (2003.04, but last version
still has the problem), while for example, DBD::Pg doesn't show
the problem.
The following patch solves the problem, and I think shows also
the reason why.
I don't know whether it's more appropriate to apply this patch
to DBI or to modify DBD::Informix::TypeInfo to return a new structure
every time. No, bad. Probably it's better to change in DBI.pm.
--- DBI.pm 2006-10-30 21:35:19.0 +0100
+++ DBI_cosimo.pm 2006-11-22 09:38:47.459177881 +0100
@@ -1713,8 +1713,11 @@
else {
my $temp = $dbh-type_info_all;
return unless $temp @$temp;
+ # make a temporary copy of tia structure returned by driver, to avoid
+ # mangling of driver's internal ref (see
$DBD::Informix::TypeInfo::type_info_all)
+ my @temp_copy = @$temp;
# we cache here because type_info_all may be expensive to call
- $tia = $dbh-{dbi_type_info_row_cache} = $temp;
+ $tia = $dbh-{dbi_type_info_row_cache} = [EMAIL PROTECTED];
$idx_hash = $dbh-{dbi_type_info_idx_cache} = shift @$tia;
}
--
Cosimo
Re: Possible strange problem in DBI::type_info()
Steffen Goeldner wrote: Cosimo Streppone wrote: Hi all, I found a strange problem in DBI::type_info(). I don't know much of DBI internals. Only found that sometimes, the 'type_info_all' structure returned by the driver is mangled by some shift() that happens in DBI::type_info(). FTR: This was the reason for this patch: http://www.xray.mpe.mpg.de/mailing-lists/dbi/2005-02/msg00085.html Has this patch been already applied? I found this problem with DBI 1.48. I didn't test it with 1.53. Should I ? [...] No, bad. Probably it's better to change in DBI.pm. Well, safety vs. efficiency - Tim should decide. I think changing DBI.pm is both safer and more efficient, because as far as I can understand, type_info_all() should be called only once in the DBI lifetime. The fact that I'm seeing this problem is probably due to multiple opening/closing of different DBI handles (for DBD::Pg DBD::Informix together). -- Cosimo
Re: Possible strange problem in DBI::type_info()
On Wed, Nov 22, 2006 at 10:50:54AM +0100, Cosimo Streppone wrote: Steffen Goeldner wrote: Cosimo Streppone wrote: Hi all, I found a strange problem in DBI::type_info(). I don't know much of DBI internals. Only found that sometimes, the 'type_info_all' structure returned by the driver is mangled by some shift() that happens in DBI::type_info(). FTR: This was the reason for this patch: http://www.xray.mpe.mpg.de/mailing-lists/dbi/2005-02/msg00085.html Has this patch been already applied? Yes, http://www.xray.mpe.mpg.de/mailing-lists/dbi/2005-02/msg00125.html I found this problem with DBI 1.48. I didn't test it with 1.53. Should I ? The patch only addressed lib/DBI/DBD/Metadata.pm - driver authors would need to rerun metadata generation, as per the release notes: =head2 Changes in DBI 1.48 (svn rev 928),14th March 2005 Fixed DBI::DBD::Metadata generation of type_info_all thanks to Steffen Goeldner (driver authors who have used it should rerun it). [...] No, bad. Probably it's better to change in DBI.pm. Well, safety vs. efficiency - Tim should decide. I think changing DBI.pm is both safer and more efficient, because as far as I can understand, type_info_all() should be called only once in the DBI lifetime. The fact that I'm seeing this problem is probably due to multiple opening/closing of different DBI handles (for DBD::Pg DBD::Informix together). Yeap. I've made the change. Thanks Cosimo! Tim.
Re: Possible strange problem in DBI::type_info()
Cosimo Streppone wrote: Hi all, I found a strange problem in DBI::type_info(). I don't know much of DBI internals. Only found that sometimes, the 'type_info_all' structure returned by the driver is mangled by some shift() that happens in DBI::type_info(). This happens only for DBD::Informix driver (2003.04, but last version still has the problem), while for example, DBD::Pg doesn't show the problem. The following patch solves the problem, and I think shows also the reason why. I don't know whether it's more appropriate to apply this patch to DBI or to modify DBD::Informix::TypeInfo to return a new structure every time. [...] FTR: This was the reason for this patch: http://www.xray.mpe.mpg.de/mailing-lists/dbi/2005-02/msg00085.html [...] No, bad. Probably it's better to change in DBI.pm. Well, safety vs. efficiency - Tim should decide. Steffen
RE: Possible strange problem in DBI::type_info()
Please remove me from this group immediately. Catrina Martin Technical Recruiter TekPartners Government Services CCR Lookup: P2P Staffing Corp DBA TekPartners DC Office: 703-682-6916 Web: www.tekpartners.com Vision. People. Service. TekPartners Quick Facts * TekPartners is a Service Disabled Veteran Owned Small Business (SDVOSB) * TekPartners has been named the 66th Fastest Growing New Company in America by PricewaterhouseCoopers Entrepreneur Magazine as part of their 2006 HOT 100 list. Click on the following URL to view our selection on the HOT 100 list: http://www.entrepreneur.com/hot100/listings/0,6868,296117-2006-60,00.html . * TekPartners was honored as the 2nd FASTEST GROWING technology company by the South Florida Business Journal. * TekPartners was honored as the 6th LARGEST Technology Consulting firm by the South Florida Business Journal. -Original Message- From: Tim Bunce [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 8:33 AM To: Cosimo Streppone Cc: DBI Users; DBI Developers; Steffen Goeldner Subject: Re: Possible strange problem in DBI::type_info() On Wed, Nov 22, 2006 at 10:50:54AM +0100, Cosimo Streppone wrote: Steffen Goeldner wrote: Cosimo Streppone wrote: Hi all, I found a strange problem in DBI::type_info(). I don't know much of DBI internals. Only found that sometimes, the 'type_info_all' structure returned by the driver is mangled by some shift() that happens in DBI::type_info(). FTR: This was the reason for this patch: http://www.xray.mpe.mpg.de/mailing-lists/dbi/2005-02/msg00085.html Has this patch been already applied? Yes, http://www.xray.mpe.mpg.de/mailing-lists/dbi/2005-02/msg00125.html I found this problem with DBI 1.48. I didn't test it with 1.53. Should I ? The patch only addressed lib/DBI/DBD/Metadata.pm - driver authors would need to rerun metadata generation, as per the release notes: =head2 Changes in DBI 1.48 (svn rev 928),14th March 2005 Fixed DBI::DBD::Metadata generation of type_info_all thanks to Steffen Goeldner (driver authors who have used it should rerun it). [...] No, bad. Probably it's better to change in DBI.pm. Well, safety vs. efficiency - Tim should decide. I think changing DBI.pm is both safer and more efficient, because as far as I can understand, type_info_all() should be called only once in the DBI lifetime. The fact that I'm seeing this problem is probably due to multiple opening/closing of different DBI handles (for DBD::Pg DBD::Informix together). Yeap. I've made the change. Thanks Cosimo! Tim.
