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

[Jason Crummack]

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* <jason.crummack at easysoft.com 
> <mailto:jason.crummack at easysoft.com>> 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* <jason.crummack at easysoft.com
>     <mailto:jason.crummack at easysoft.com>
>     > <mailto: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/
>     <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/
>
>     _______________________________________________
>     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/dbix-class@lists.rawmode.org/
>
>
>
>
> -- 
> 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/dbix-class@lists.rawmode.org/