2011/11/29 Brendan Byrd <sineswi...@gmail.com>:
> Found a potential bug, but it looks deliberate, so I wanted to see why it
> was coded that way. In SQL::Statement, open_tables is using $self->tables()
> for mostly everything, which will contain the correct case for all of the
> table names. (IE: FOOBAR = foobar and "FOOBAR" = FOOBAR) However, when
> calling open_table (the DBD method), it uses the following code:
>
> undef $@;
> eval {
> my $open_name = $self->{org_table_names}->[$count];
> $t->{$name} = $self->open_table( $data, $open_name,
> $createMode, $lockMode );
> };
>
> So, it's deliberately grabbing the untouched (pre-corrected) table name from
> org_table_names and passing it to open_table. What's the reasoning behind
> this?
The reason is quite simple. The "corrected" table name is not corrected from
the point of view of the storage backend (in case of DBD::CSV the file
names on disk),
they are corrected from point of view of SQL standard and SQL indentifier
attribute (lower case all, upper case all, leave them as they were).
The storage backend might need to do it's own correction, as DBD::File
does.
> Should we worry about it or not?
Well, I don't worry about this for SQL::Statement 1.xxx.
> If we correct it to enforce proper
> ODBC case-sensitivity, that may suddenly break the DBD and users of those
> DBDs that are expecting to query a CSV DB via "SELECT * FROM
> UPPERCASE_filename" and getting an error because it's now going to convert
> that to lowercase. If we don't correct it, there's the potential for two
> different cased files to have the same table key and screwing stuff up with
> JOIN. (Yeah, it's rare for somebody to actually be using both "FOOBAR" and
> "foobar" in the same query...)
I hope this wouldn't happen, because SQL::Statement should detect (and
internally
correct /FOOBAR/ and /foobar/ into /foobar/, but in fact, I'm not sure.
You might go ahead and add a test for this.
> I guess this is delegating the enforcement of these standards to the DBD, or
> should it be higher up?
This is handled by the base class of all SQL::Statement based DBD's, in
DBI::DBD::SqlEngine. See sql_identifier_case and sql_quoted_identifier_case
$dbh attribute description.
DBD::File acts upon the values of those attributes, but other DBD's might
implement other actions.
I agree in fundamental issues in S::S and DBI::DBD interaction with standards.
The reason to create DBI::DBD::SqlEngine was primarily to introduce an
abstraction layer to hide SQL::Statement details and issues. From view of
any DBD derived from DBI::DBD::SqlEngine, details should be hidden in
SqlEngine. All changes we make must not affect this API for now.
We all agree (all we talked 2 years ago named Merijn Brand, Martin Evans,
Tim Bunce and myself), that we might need one big shot for a new
DBI::DBD::SqlEngine API - but for stability reasons please no regular
"improvements". I see how long it took for example for Steffen Winkler to
improve his DBD::MO (or myself for DBD::AnyData) to the new
Pure-Perl-DBD-API.
Further, I've seen you got a lot of DBI/DBD related information yesterday
(I was busy at $work and couldn't talk on IRC). What was still missing
was enlightening you about DBI::DBD::SqlEngine and DBD::File/DBD::DBM
internal details. Probably we find a day were we can talk, but for the
moment the guys guided you yesterday can help you further patching
your own repository checkouts and create tests for your patches and
guide you how to test dependent modules.
I'm the last one who will reject good patches with tests on SQL::Statement
and approvals for DBI and tests on DBI, DBD::CSV and DBD::Sys
running fine.
There is a reason for the http://search.cpan.org/dist/Bundle-Test-SQL-Statement/
distribution - it's test coverage. Probably Tux as DBD::CSV maintainer can agree
that issues between SQL::Statement changes and Pure-Perl-DBD's are
getting rarer since these Tests exist.
Best regards,
Jens
> --
> Brendan Byrd/SineSwiper <sineswi...@gmail.com>
> Computer tech, Perl wizard, and all-around Internet guru
