DBD::CSV: Problem with file-name-extensions

In this script I have problems with file-name-extensions: if I use /home/mm/test_x it works, with file named /home/mm/test_x.csv it doesn't:

#!/usr/bin/env perl
use warnings; use strict;
use 5.012;
use DBI;

my $table_1 = '/home/mm/test_1.csv';
my $table_2 = '/home/mm/test_2.csv';
#$table_1 = '/home/mm/test_1';
#$table_2 = '/home/mm/test_2';

my $dbh = DBI->connect( "DBI:CSV:" );
$dbh->{RaiseError} = 1;

$table_1 = $dbh->quote_identifier( $table_1 );
$table_2 = $dbh->quote_identifier( $table_2 );

my $sth = $dbh->prepare( "SELECT a.id, a.name, b.city FROM $table_1 AS a NATURAL JOIN $table_2 AS b" );

$sth->exec开发者_JAVA百科ute;
$sth->dump_results;
$dbh->disconnect;

Output with file-name-extention:

DBD::CSV::st execute failed:

Execution ERROR: No such column '"/home/mm/test_1.csv".id' called from /usr/local/lib/perl5/site_perl/5.12.0/x86_64-linux/DBD/File.pm at 570.

Output without file-name-extension:

'1', 'Brown', 'Laramie'

'2', 'Smith', 'Watertown'

2 rows

Is this a bug?

cat test_1.csv

id,name

1,Brown

2,Smith

5,Green

cat test_2.csv

id,city

1,Laramie

2,Watertown

8,Springville

DBD::CSV provides a way to map the table names you use in your queries to filenames. The same mechanism is used to set up per-file attributes like line ending, field separator etc. look for 'csv_tables' in the DBD::CSV documentation.

#!/usr/bin/env perl

use warnings;
use strict;

use DBI;

my $dbh = DBI->connect("DBI:CSV:f_dir=/home/mm", { RaiseError => 1 });
$dbh->{csv_tables}->{table_1} = {
    'file' => 'test_1.csv',
    'eol' => "\n",
};
$dbh->{csv_tables}->{table_2} = {
    'file' => 'test_2.csv',
    'eol' => "\n",
};

my $sth = $dbh->prepare( "SELECT a.id, a.name, b.city FROM table_1 AS a NATURAL JOIN table_2 AS b" );

$sth->execute();
$sth->dump_results();
$dbh->disconnect();

In my case I had to specify a line ending character, because I created the CSV files in vi so they ended up with Unix line endings whereas DBD::CSV assumes DOS/Windows line-endings regardless of the platform the script is run on.

I looks like even this works:

#!/usr/bin/env perl
use warnings; use strict;
use 5.012;
use DBI;

my $dbh = DBI->connect("DBI:CSV:f_dir=/home/mm/Dokumente", undef, undef, { RaiseError => 1, });

my $table = 'new.csv';
$dbh->do( "DROP TABLE IF EXISTS $table" );
$dbh->do( "CREATE TABLE $table ( id INT, name CHAR(64), city CHAR(64) )" );
my $sth_new = $dbh->prepare( "INSERT INTO $table( id, name, city ) VALUES ( ?, ?, ? )" );

$dbh->{csv_tables}->{table_1} = { 'file' => '/tmp/test_1.csv', 'eol' => "\n", };
$dbh->{csv_tables}->{table_2} = { 'file' => '/tmp/test_2.csv', 'eol' => "\n", };
my $sth_old = $dbh->prepare( "SELECT a.id, a.name, b.city FROM table_1 AS a NATURAL JOIN table_2 AS b" );
$sth_old->execute();

while ( my $hash_ref = $sth_old->fetchrow_hashref() ) {
    state $count = 1;
    $sth_new->execute( $count++, $hash_ref->{'a.name'}, $hash_ref->{'b.city'} );
}
$dbh->disconnect();

I think you might want to take a look at the f_ext and f_dir attributes. You can then class your table names as "test_1" and "test_2" without the csv but the files used will be test_1.csv and test_2.csv. The problem with a dot in the table name is a dot is usually used for separating the schema from the table name (see f_schema).