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

[Zbigniew Lukasiak]

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> 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 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 > 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/
>
> _______________________________________________
> 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/
>



-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rawmode.org/pipermail/dbix-class/attachments/20060822/43cdffb2/attachment-0001.htm