Skip Menu |

This queue is for tickets about the DBI CPAN distribution.

Report information
The Basics
Id: 93204
Status: open
Priority: 0/
Queue: DBI
People
Owner: Nobody in particular
Requestors: Dan [...] DWright.Org
Cc: ribasushi [...] leporine.io
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Thu Feb 20 13:58:42 2014 Dan [...] DWright.Org - Ticket created
Subject: Uninitialized warnings in SqlEngine.pm
Hello, After upgrading to the most recent DBI, I'm getting the following warning, a lot: Use of uninitialized value in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.8.3/i386-freebsd/DBI/DBD/SqlEngine.pm line 580. Use of uninitialized value in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.8.3/i386-freebsd/DBI/DBD/SqlEngine.pm line 581. Here is the offending code from sub FETCH: 574 unless ($attr_prefix) 575 { 576 ( my $drv_class = $dbh->{ImplementorClass} ) =~ s/::db$//; 577 $attr_prefix = DBI->driver_prefix($drv_class); 578 $attrib = $attr_prefix . $attrib; 579 } 580 my $valid_attrs = $attr_prefix . "valid_attrs"; 581 my $ro_attrs = $attr_prefix . "readonly_attrs"; The problem is that I'm connecting via my module, DBD::Multi, which isn't registered inside DBI, so driver_prefix() is returning undef. I wonder if perhaps $attr_prefix could be changed to an empty string rather than undef in cases where a DBD module has not been registered with DBI? Thanks, -Dan
  Thu Feb 20 14:00:56 2014 Dan [...] DWright.Org - Correspondence added
From: Dan [...] DWright.Org
On Thu Feb 20 13:58:42 2014, DWRIGHT wrote: *facepalm* -- This ticket should have been put into the DBI queue, not the DBD-Pg queue. Sorry about that!
  Thu Feb 20 14:05:49 2014 dwheeler [...] cpan.org - Queue changed from DBD-Pg to DBI
  Thu Feb 20 14:06:07 2014 dwheeler [...] cpan.org - Correspondence added
On 2014-02-20 14:00:56, DWRIGHT wrote: Show quoted text
> On Thu Feb 20 13:58:42 2014, DWRIGHT wrote: > > *facepalm* -- This ticket should have been put into the DBI queue, > not the DBD-Pg queue. > > Sorry about that!
NP, I moved it.
  Thu Feb 20 14:06:07 2014 The RT System itself - Status changed from 'new' to 'open'
  Thu Feb 20 15:04:27 2014 REHSACK [...] cpan.org - Correspondence added
I would need more information about the context, otherwise I would assume a dirty hack (read: you're using a driver without registered prefix). From my perspective this isn't a bug, it works as designed.
  Thu Feb 20 15:15:47 2014 Dan [...] DWright.Org - Correspondence added
CC: TIMB [...] cpan.org
Subject: Re: [rt.cpan.org #93204] Uninitialized warnings in SqlEngine.pm
Date: Thu, 20 Feb 2014 15:15:40 -0500
To: bug-DBI [...] rt.cpan.org
From: Daniel Wright <dan [...] dwright.org>
On Feb 20, 2014, at 3:04 PM, Jens Rehsack via RT <bug-DBI@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=93204 > > > I would need more information about the context, otherwise I would assume a dirty hack (read: you're using a driver without registered prefix). > > From my perspective this isn't a bug, it works as designed.
I’m not sure I understand what you mean by “dirty hack.” Are you suggesting that if a DBD driver has not been registered with DBI, then DBI is designed to fail when using it?
  Thu Feb 20 15:24:38 2014 REHSACK [...] cpan.org - Correspondence added
I'm saying, that DBI::DBD::SqlEngine is designed that way (because we need more information about users ^^). But SqlEngine is made in a generic way supporting driver attributes by registered prefix in DBI. I'm open for proposals, but that's the current design.
  Thu Feb 20 15:35:23 2014 Dan [...] DWright.Org - Correspondence added
Subject: Re: [rt.cpan.org #93204] Uninitialized warnings in SqlEngine.pm
Date: Thu, 20 Feb 2014 15:35:18 -0500
To: bug-DBI [...] rt.cpan.org
From: Daniel Wright <dan [...] dwright.org>
On Feb 20, 2014, at 3:24 PM, Jens Rehsack via RT <bug-DBI@rt.cpan.org> wrote: Show quoted text
> I'm saying, that DBI::DBD::SqlEngine is designed that way (because we need more information about users ^^).
Hmm.. okay. I note that back in 2010, your e-mail to me implied that registration was optional: http://www.nntp.perl.org/group/perl.dbi.dev/2010/08/msg6206.html But that was 4 years ago. So perhaps it is no longer applicable. The most straightforward solution for my present issue may simply be to request to have DBD::Multi registered with DBI. How may I do that? However, I still believe there is a greater issue here: I suspect that there are a lot of cases where not all users are able to share their information with you. DBI is one of the most popular modules in CPAN. I’m sure there are a lot of people using it in proprietary ways that they just can’t share. The Robustness principle would suggest that it would be best if DBI allowed them to continue doing what they do, without emitting warnings. However, if you are absolutely set on the design decision that SqlEngine is supposed to break when you use it with an unregistered driver, then I recommend you make it die explicitly rather than allow it to output cryptic warnings.
  Thu Feb 20 16:17:22 2014 REHSACK [...] cpan.org - Correspondence added
On Thu Feb 20 15:35:23 2014, DWRIGHT wrote: Show quoted text
> > On Feb 20, 2014, at 3:24 PM, Jens Rehsack via RT <bug-DBI@rt.cpan.org> > wrote: >
> > I'm saying, that DBI::DBD::SqlEngine is designed that way (because we > > need more information about users ^^).
> > Hmm.. okay. > > I note that back in 2010, your e-mail to me implied that registration > was optional: > > http://www.nntp.perl.org/group/perl.dbi.dev/2010/08/msg6206.html > > But that was 4 years ago. So perhaps it is no longer applicable.
Exactly ;) The initial recommendation was around a time where DBD::File deals with all the generic derived ones, but nowadays the most of the methods got refactored into common base class. It is also mentioned in the doc that it's assumed: http://search.cpan.org/dist/DBI/lib/DBI/DBD/SqlEngine/HowTo.pod#CREATING_DRIVER_CLASSES Show quoted text
> The most straightforward solution for my present issue may simply be > to request to have DBD::Multi registered with DBI. How may I do > that?
This should be enough - how sounds dmu_? (substitute d with E and u with c^2 and you have the world formula \o/) Show quoted text
> However, I still believe there is a greater issue here: I suspect > that there are a lot of cases where not all users are able to share > their information with you. DBI is one of the most popular modules > in CPAN. I’m sure there are a lot of people using it in proprietary > ways that they just can’t share. The Robustness principle would > suggest that it would be best if DBI allowed them to continue doing > what they do, without emitting warnings.
I can imagine several ways: 1) DBI generates on request a prefix based on driver name 2) DBI allows self-registration (eg. by allowing DBI->driver_prefix being a setter, too) 3) you replace DBI::driver_prefix by your own method and call SUPER unless a private driver prefix is requested 4) DBI::DBD::SqlEngine caches driver prefixes (to avoid expensive calls when FETCH/STORE attributes) - this can be overloaded in sub-classes Well, when I continue I would get more ideas, but I think none of them fits every requirement perfectly. For Open-Source drivers I recommend requesting a prefix, for closed source I recommend 3. Show quoted text
> However, if you are absolutely set on the design decision that > SqlEngine is supposed to break when you use it with an unregistered > driver, then I recommend you make it die explicitly rather than allow > it to output cryptic warnings.
This is true and could be done easily during initialisation. Cheers, Jens
  Thu Feb 20 17:00:55 2014 Dan [...] DWright.Org - Correspondence added
Subject: Re: [rt.cpan.org #93204] Uninitialized warnings in SqlEngine.pm
Date: Thu, 20 Feb 2014 17:00:47 -0500
To: bug-DBI [...] rt.cpan.org
From: Daniel Wright <dan [...] dwright.org>
On Feb 20, 2014, at 4:17 PM, Jens Rehsack via RT <bug-DBI@rt.cpan.org> wrote: Show quoted text
> The initial recommendation was around a time where DBD::File deals with all the generic derived ones, but nowadays the most of the methods got refactored into common base class.
Good to know. Thanks. Show quoted text
>> The most straightforward solution for my present issue may simply be >> to request to have DBD::Multi registered with DBI. How may I do >> that?
> > This should be enough - how sounds dmu_? (substitute d with E and u with c^2 and you have the world formula \o/)
Sounds fine to me. Show quoted text
> I can imagine several ways: > 1) DBI generates on request a prefix based on driver name
This would be my suggestion. Show quoted text
> 2) DBI allows self-registration (eg. by allowing DBI->driver_prefix being a setter, too)
Not a bad idea, except that if you let every CPAN author pick their own arbitrary prefix, you run the risk of multiple people picking the same thing, or somebody doing something evil by intentionally over-writing an existing prefix. At first, I was going to recommend throwing an exception if a driver attempts to register an already-registered prefix. But on further consideration, I can see cases where that might be useful. Show quoted text
> 3) you replace DBI::driver_prefix by your own method and call SUPER unless a private driver prefix is requested
I like this idea, also. Right now there is code in DBI that is calling driver_prefix() like this: 577 $attr_prefix = DBI->driver_prefix($drv_class); The code would need to be updated to look like this: $attr_prefix = $drv_class->driver_prefix() However you’d still have two challenges: 1) Making this change in a backwards-compatible way. 2) You’re still vulnerable to namespace collisions. Show quoted text
> 4) DBI::DBD::SqlEngine caches driver prefixes (to avoid expensive calls when FETCH/STORE attributes) - this can be overloaded in sub-classes
Also an interesting solution. Show quoted text
> Well, when I continue I would get more ideas, but I think none of them fits every requirement perfectly. For Open-Source drivers I recommend requesting a prefix, for closed source I recommend 3.
Fair enough. Thank you for your help. -Dan
  Thu Feb 20 17:16:42 2014 REHSACK [...] cpan.org - Correspondence added
On Thu Feb 20 17:00:55 2014, DWRIGHT wrote: Show quoted text
>
Show quoted text
> I like this idea, also. Right now there is code in DBI that is > calling driver_prefix() like this: > > 577 $attr_prefix = DBI->driver_prefix($drv_class);
See Package::Stash what I mean with "replacing DBI::driver_prefix" ;) Show quoted text
> The code would need to be updated to look like this: > > $attr_prefix = $drv_class->driver_prefix()
Which is option 4 - but this would have to deal with the entire inheritance tree. Show quoted text
> However you’d still have two challenges: > > 1) Making this change in a backwards-compatible way. > 2) You’re still vulnerable to namespace collisions.
As said, you can't solve that except we force registering an official name. Wise fortune said once: "You cannot have everything, you have not enough room to store it" :) Show quoted text
> > 4) DBI::DBD::SqlEngine caches driver prefixes (to avoid expensive > > calls when FETCH/STORE attributes) - this can be overloaded in sub- > > classes
> > Also an interesting solution.
It doesn't lack of phantasy to find a solution. You've seen that no solution rules them all. Show quoted text
> > Well, when I continue I would get more ideas, but I think none of > > them fits every requirement perfectly. For Open-Source drivers I > > recommend requesting a prefix, for closed source I recommend 3.
> > Fair enough.
I think we should improve documentation about those two options driver authors have. Cheers, Jens
  Tue Feb 25 17:47:30 2014 TIMB [...] cpan.org - Correspondence added
Hello Daniel. I'll register DBD::Multi with 'multi_' as the prefix in the next DBI release, if that's ok with you. Jens, I agree with Daniel that using a non-registered driver should trigger at least a clear warning. I don't want to add self-registration to the DBI, but SqlEngine (or whatever) could support an override mechanism for such cases if it's important enough. (It doesn't seem to be important to me. I've never refused driver registration. It's a formality just to ensure a unique prefix.) For the 'closed source' the x_ prefix may be useful as it's reserved for 'private use'. However that probably doesn't fit this use case. Anyway, in summary, it seems that getting DBD::Multi registered will resolve this case.
  Wed Feb 26 03:55:38 2014 ribasushi [...] leporine.io - Cc RIBASUSHI added