On 8/21/06, Jason Crummack <[EMAIL PROTECTED]> wrote:
Yeah that was a silly error, I've correct that in trunk.
Probably true. On the flipside, I think its possible that people have been getting away in the past with "CREATE TABLE FOOTABLE" in Oracle combined with __PACKAGE__->table('footable') in DBIC, and this uc() thing was basically a workaround for such sloppiness. It would be nice if case-sensitive identifiers were *always* case sensitive, so that people would never have the opportunity to make such a mistake. The roots of this issue may run deeper into DBD::Oracle or the client library (or the general failure of Oracle users to understand the exact nature of the Oracle standards for identifier case).
I would assume this is a case issue, yes.
It is a catch-all for when colum_info doesn't work (even if it seems to work but then returns zero rows of information).
In general, I'd say ignore columns_info_for issues for now, unless its really breaking something and the fix is obvious and easy. If things go as they seem they will with the -current branch, in the upcoming DBIC 0.08xxx series, it will not be used by default (you'll have to ask for it specifically) and will be marked deprecated, and it will eventually completely go away by 1.0. The functionality will be subsumed into DBIx::Class::Schema::Loader, which is a more appropriate place for the kind of heuristic automagic hackery that is columns_info_for().
-- Brandon
Hi,
Firstly the current version of Storage/DBI/Oracle.pm won't make test on
either Oracle XE or 10.2, the offending line is in columns_info_for, I
didn't think $self->next::method needs to pass $self in the arguments list?
Yeah that was a silly error, I've correct that in trunk.
Secondly at Matt's request I've been looking into providing test cases
to prove the Oracle layer against case sensitive table names, but
unfortunately I'm having problems getting past the columns_info_for code.
If the table name is case sensitive (or a reserved word) then the
uppercase code in columns_info_for (DBI/Oracle.pm) shouldn't be done,
the table name should be passed to DBD::Oracle as is.
Probably true. On the flipside, I think its possible that people have been getting away in the past with "CREATE TABLE FOOTABLE" in Oracle combined with __PACKAGE__->table('footable') in DBIC, and this uc() thing was basically a workaround for such sloppiness. It would be nice if case-sensitive identifiers were *always* case sensitive, so that people would never have the opportunity to make such a mistake. The roots of this issue may run deeper into DBD::Oracle or the client library (or the general failure of Oracle users to understand the exact nature of the Oracle standards for identifier case).
The other problem I've seen (which is probably a side effect of the
uppercasing) is that the column_info call can return different datasets
for the same table, the table I used was the artist table (t/73oracle.t)
if column_info runs successfully all column names are returned uppercase
and datatypes match initial creation types but if column_info isn't
returned and the select * from table where 1 = 0 runs column names are
returned in lowercase and certain datatype names are changed (number
becomes decimal).
I would assume this is a case issue, yes.
Which drivers use the select * from table where 1=0 code intentionally,
or is it simply a catch all for failing column_info calls?
It is a catch-all for when colum_info doesn't work (even if it seems to work but then returns zero rows of information).
In general, I'd say ignore columns_info_for issues for now, unless its really breaking something and the fix is obvious and easy. If things go as they seem they will with the -current branch, in the upcoming DBIC 0.08xxx series, it will not be used by default (you'll have to ask for it specifically) and will be marked deprecated, and it will eventually completely go away by 1.0. The functionality will be subsumed into DBIx::Class::Schema::Loader, which is a more appropriate place for the kind of heuristic automagic hackery that is columns_info_for().
-- Brandon
_______________________________________________ List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class Wiki: http://dbix-class.shadowcatsystems.co.uk/ IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/ Searchable Archive: http://www.mail-archive.com/[email protected]/
