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