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.
FW: the same compiler that was used...
Hi Tim et al. Please see the suggestion below for an amendment to the DBI readme. Sounds like a good idea to me. Regards, Philip -Original Message- From: Steve Canfield [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 12:24 PM To: dbi-users@perl.org Subject: RE: the same compiler that was used... Thanks Philip! This morning before your email arrived it occured to me that binary Perl modules might be installed through Synatpic package manager the same way I installed gcc. For DBI and LWP that turned out to be the case. Installing libc6-dev (using Synaptic) allowed me to install the WeakRef perl module. I suspect that installing libc6-dev would have allowed me to compile DBI. So it perhaps the README for DBI could be expanded just a little. As I read the relevent section, it appears that there is only one solution to the problem: recompile Perl. Here's the section in question: If you get compiler errors refering to Perl's own header files (.../CORE/*.h) or the compiler complains about bad options etc then there is something wrong with your installation. It is best to use a Perl that was built on the system you are trying to use and it's also important to use the same compiler that was used to build the Perl you are using. There may be two other ways to address the problem. Perhaps something like this would guide people towards solutions: If you installed Perl using a binary distribution, such as ActiveState Perl, or if Perl came installed with the operating system you use, such as Debian or Ubuntu, then you may be able to install a precompiled binary of DBI using a package manager. Check the package manager for your distribution of Perl (e.g. ppm for ActiveState) or for your operating system (e.g Synaptic for Ubuntu). See [some URL here] for more information about package managers. You may also be able to augment your compiler with [not sure what to put here, perhaps someone in this mailing list can come up with something]. --- Garrett, Philip (MAN-Corporate) [EMAIL PROTECTED] wrote: Steve Canfield wrote: the same compiler that was used... [snip] The entirety of the output of perl Makefile.PL, make, and perl -V are echoed below. However, I believe the problem lies in this error and others like it: /usr/lib/perl/5.8/CORE/perl.h:382:24: error: sys/types.h: No such file or directory Looks to me like you need the libdevel/libc6-dev package: http://packages.ubuntu.com/edgy/libdevel/libc6-dev Good luck! Regards, Philip __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
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.
Fwd: [Pdl-porters] PDL - RDBMS linkage
-- Forwarded message --
From: Jonathan Scott Duff [EMAIL PROTECTED]
Date: Nov 22, 2006 2:45 PM
Subject: Re: [Pdl-porters] PDL - RDBMS linkage
To: [EMAIL PROTECTED]
Cc: pdl-porters@jach.hawaii.edu, [EMAIL PROTECTED]
On 11/22/06, Doug Hunt [EMAIL PROTECTED] wrote:
Hi Jonathan: I've done a bit of messing around with postgres and PDL.
To get a list postgres 1D arrays into a 2D PDL, I do this:
my $p = pdl ( map { tr /{}/[]/ eval }
@{$dbh-selectcol_arrayref($sql)} );
I'm kind of looking for a way to get perl out from in between the DBMS and
PDL. Sure, I can pull all of the data from the DBMS into perl-space and then
create a piddle from that, but it would be nicer if there were a way to do
something like this:
use PDL;
use DBI;
use DBI2PDL; # okay, this name sucks, but work with me here :)
# ...
my $p = $sth-fetchrow_pdl;# or ...
my $q = $sth-fetchall_pdl; # or whatever ...
Basically I'm thinking that this hypothetical module would add *_pdl
routines that would complement the *_array routines of DBI. Of course there
will have to be some smarts to deal with non-numeric columns and such, but
that's a detail best left for an actual implementation. :-)
I don't know enough about PDL's insides to know just how possible this is
and I just realized that I probably don't know enough about DBI's insides
either.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Fwd: [Pdl-porters] PDL - RDBMS linkage
Jonathan Scott Duff wrote: I'm kind of looking for a way to get perl out from in between the DBMS and PDL. Sure, I can pull all of the data from the DBMS into perl-space and then create a piddle from that, but it would be nicer if there were a way to do something like this: use PDL; use DBI; use DBI2PDL; # okay, this name sucks, but work with me here :) # ... my $p = $sth-fetchrow_pdl;# or ... my $q = $sth-fetchall_pdl; # or whatever ... Basically I'm thinking that this hypothetical module would add *_pdl routines that would complement the *_array routines of DBI. Of course there will have to be some smarts to deal with non-numeric columns and such, but that's a detail best left for an actual implementation. :-) I don't know enough about PDL's insides to know just how possible this is and I just realized that I probably don't know enough about DBI's insides either. -Scott Disclaimer: I'm blissfully ignorant of PDL other than knowing its a number crunching tool. 1. Consider a DBI subclass (as a DBIx extension, e.g., DBIx::PDL). Presumably, adding a couple functions such as you're after should be straightforward, while preserving all the other DBI semantics/syntax. 2. And (as an SQL fanboy) I'd consider the ultimate disintermediation: a DBI subclass to make it appear that PDL was running in the DBMS. See DBIx::Chart for a similar concept applied to charting. It would be interesting to see a SQL extension with matrix operators (perhaps as some sort of exotic JOIN ?): my $dbh = DBIx::PDL-connect($dsn, $user, $passwd); my $results = $dbh-selectall_arrayref( 'SELECT * from (SELECT * from TABLE1) a X (SELECT * FROM TABLE2) b'); (Yes, my claims to sanity are often disputed). Dean Arnold Presicient Corp.
