[Dbix-class] Problems using Oracle under DBIx::Class

[Jason Crummack]

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 to only uppercase the table name if quote_char is not set?

Jason
Easysoft Limited


Brandon Black wrote:
>
>
> On 8/21/06, *Jason Crummack* <jason.crummack at easysoft.com 
> <mailto:jason.crummack at easysoft.com>> 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/
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
> Searchable Archive: http://www.mail-archive.com/dbix-class@lists.rawmode.org/