Thanks I'll do that and see what happens. Jason
Zbigniew Lukasiak wrote: > 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. > > -- > Zbyszek > > On 8/22/06, *Jason Crummack* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > The problem I have is the uppercasing now causes a table I have (old > legacy system in which I can't change its name) to fail. > > Previously turning on the quote_char and specifying the correct > case in > the class definition for the table, all worked well. In the short > term > would there be a problem putting a small change into > columns_info_for in > Oracle.pm <http://Oracle.pm> to only uppercase the table name if > quote_char is not set? > > Jason > Easysoft Limited > > > Brandon Black wrote: > > > > > > On 8/21/06, *Jason Crummack* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>> wrote: > > > > 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/ > <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]/ > > _______________________________________________ > List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class > <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/ > <http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/> > Searchable Archive: > http://www.mail-archive.com/[email protected]/ > > > > > -- > Zbigniew Lukasiak > http://brudnopis.blogspot.com/ > ------------------------------------------------------------------------ > > _______________________________________________ > 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]/ _______________________________________________ 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]/
