Re: Any reasons not to release DBI 1.614?
On Tue, 31 Aug 2010 21:07:46 -0700, Darren Duncan wrote: > Tim Bunce wrote: > > On Tue, Aug 31, 2010 at 08:55:32AM -0700, David E. Wheeler wrote: > >> On Aug 31, 2010, at 2:52 AM, Tim Bunce wrote: > >> > >>> It's back in. I may remove it for 1.615 or, more likely, may leave it out > >>> and > >>> individual developers deal with failure reports on perl 5.13.3+/5.14. > >> You may “remove it…or, more likely, leave it out”? Huh? > > > > Ug. I meant "may restore it or, more likely, leave it out". > > > > Thanks. > > > > Tim. > > I suggest releasing DBI *without* the pollute stuff and let the drivers catch > up. The drivers would still work with Perls before 5.13 without changes. In > particular, it will make it much easier to test that drivers are correct if > DBI > isn't muddling things up by perpetuating the pollution. -- Darren Duncan Though I mentally support this stand, I'm a bit worried about DBD's that do not have active maintainers and will suddenly fail when DBI is upgraded and there will be noone available for a quick fix. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Any reasons not to release DBI 1.614?
Tim Bunce wrote: On Tue, Aug 31, 2010 at 08:55:32AM -0700, David E. Wheeler wrote: On Aug 31, 2010, at 2:52 AM, Tim Bunce wrote: It's back in. I may remove it for 1.615 or, more likely, may leave it out and individual developers deal with failure reports on perl 5.13.3+/5.14. You may “remove it…or, more likely, leave it out”? Huh? Ug. I meant "may restore it or, more likely, leave it out". Thanks. Tim. I suggest releasing DBI *without* the pollute stuff and let the drivers catch up. The drivers would still work with Perls before 5.13 without changes. In particular, it will make it much easier to test that drivers are correct if DBI isn't muddling things up by perpetuating the pollution. -- Darren Duncan
Re: Any reasons not to release DBI 1.614?
On Aug 31, 2010, at 1:08 PM, Tim Bunce wrote: >>> It's back in. I may remove it for 1.615 or, more likely, may leave it out >>> and >>> individual developers deal with failure reports on perl 5.13.3+/5.14. >> >> You may “remove it…or, more likely, leave it out”? Huh? > > Ug. I meant "may restore it or, more likely, leave it out". But you said “It's back in,” so I don't think you can restore it if it's already restored. Confused, David
Re: [svn:dbi] r14361 - dbi/trunk/t
On Mon, Aug 30, 2010 at 01:49:10PM -0700, hmbr...@cvs.perl.org wrote:
> Log:
> Fix for failing t/50 when old SQL::Statement available (e.g. 1.16)
Does this fix http://www.cpantesters.org/cpan/report/8392757 ?
> my $dbi_sql_nano = $ENV{DBI_SQL_NANO};
> unless( $dbi_sql_nano ) {
> -$@ = undef;
> +my $haveSS = 0;
> eval {
> require SQL::Statement;
> + $haveSS = DBD::DBM::Statement->isa('SQL::Statement');
> };
> -$@ and $dbi_sql_nano = 1;
> +$dbi_sql_nano = !$haveSS;
> }
Could this:
> my $dbi_sql_nano = $ENV{DBI_SQL_NANO};
> unless( $dbi_sql_nano ) {
> my $haveSS = 0;
> eval {
>require SQL::Statement;
>$haveSS = DBD::DBM::Statement->isa('SQL::Statement');
> };
> $dbi_sql_nano = !$haveSS;
> }
be expressed as:
my $dbi_sql_nano = $ENV{DBI_SQL_NANO};
unless( $dbi_sql_nano ) {
$dbi_sql_nano = not eval {
require SQL::Statement;
DBD::DBM::Statement->isa('SQL::Statement');
};
}
or even
# use Nano if requested or if SQL::Statement isn't usable for DBD::DBM
my $dbi_sql_nano = $ENV{DBI_SQL_NANO} || not eval {
require SQL::Statement; DBD::DBM::Statement->isa('SQL::Statement')
};
Tim.
Re: Any reasons not to release DBI 1.614?
On Tue, Aug 31, 2010 at 08:55:32AM -0700, David E. Wheeler wrote: > On Aug 31, 2010, at 2:52 AM, Tim Bunce wrote: > > > It's back in. I may remove it for 1.615 or, more likely, may leave it out > > and > > individual developers deal with failure reports on perl 5.13.3+/5.14. > > You may “remove it…or, more likely, leave it out”? Huh? Ug. I meant "may restore it or, more likely, leave it out". Thanks. Tim.
Re: Any reasons not to release DBI 1.614?
On Aug 31, 2010, at 2:52 AM, Tim Bunce wrote: > It's back in. I may remove it for 1.615 or, more likely, may leave it out and > individual developers deal with failure reports on perl 5.13.3+/5.14. You may “remove it…or, more likely, leave it out”? Huh? David
Re: Any reasons not to release DBI 1.614?
On Mon, Aug 30, 2010 at 02:15:32PM -0700, Darren Duncan wrote: > Tim Bunce wrote: > >What's the state of play? > > Will DBI 1.614 still lack the POLLUTE or did you put that back in? -- Darren > Duncan It's back in. I may remove it for 1.615 or, more likely, may leave it out and individual developers deal with failure reports on perl 5.13.3+/5.14. Tim.
