Skip Menu |

This queue is for tickets about the SQL-Statement CPAN distribution.

Report information
The Basics
Id: 48502
Status: resolved
Priority: 0/
Queue: SQL-Statement

People
Owner: Nobody in particular
Requestors: JDB [...] cpan.org
SREZIC [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 1.21_1
Fixed in: 1.22



Subject: 1.21_1 possibly breaks testsuites of other modules
The following distributions: DBIx-InterpolationBinding-1.00 DBIx-Connect-FromConfig-0.04 Coat-Persistent-0.210 fail with the newest developer version of SQL-Statement, but seem to run OK with an older version (1.15). There is already another RT ticket for the Coat::Persistent test failure: https://rt.cpan.org/Ticket/Display.html?id=48469 Regards, Slaven
Subject: SQL-Statement breaks DBD::CSV
The attached test script fails with the following errors: not ok 4 # Test 4 got: <UNDEF> (csv.pl at line 24) # Expected: "2" # csv.pl line 24 is: ok($row->{id}, 2); not ok 5 # Test 5 got: <UNDEF> (csv.pl at line 25) # Expected: "foo" # csv.pl line 25 is: ok($row->{name}, "foo"); It works correctly with SQL-Statement 1.15. Using Perl 5.10.0 and DBI 1.609
Subject: csv.pl
use strict; use warnings; use DBI; use Test; plan tests => 6; my $table = "table$$"; unlink($table) if -f $table; my $dbh = DBI->connect("DBI:CSV:"); ok(defined $dbh); $dbh->do("CREATE TABLE $table (id INTEGER, name CHAR(64))"); $dbh->do("INSERT INTO $table VALUES (?, ?)", undef, 2, "foo"); my $sth = $dbh->prepare("SELECT * FROM $table WHERE id > 1 ORDER BY id"); $sth->execute(); my $row = $sth->fetchrow_hashref; ok(defined $row); ok(ref($row), "HASH"); ok($row->{id}, 2); ok($row->{name}, "foo"); $row = $sth->fetchrow_hashref; ok(!$row); $sth->finish(); $dbh->disconnect(); unlink($table);
Subject: SQL-Statement breaks DBD::CSV
Ever tried to check if anyone before you opened a similar report? Or took a look into Changes where is told: "[Things that may break your code]...". Sorry when being unfriendly, but hacking opens source software should be mainly fun and is done in free time - I don't see any reason for reporting a critical problem in a developer version of a module.
On Tue Aug 11 02:46:35 2009, REHSACK wrote: Show quoted text
> I don't see any reason for > reporting a critical problem in a developer version of a module.
Then I don't understand what's the purpose of a developer version --- I thought it's just the point to find problems before a stable version is done? Regards, Slaven
Should be resolved in 1.22