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

Zbigniew Lukasiak zzbbyy at gmail.com
Tue Aug 22 09:36:56 CEST 2006


Hi,

As the original author of the columns_info_for I say thanks for moving it
out from the core DBIC - I was a bit ignorat about the whole DBIC
architecture when I was writing it.  It's causing lots of problems - because
everyone expects different case magic there and also it's relation to the
data types you can declare in the definition of the DBIC classes is a bit
fuzzy.

--
Zbyszek

On 8/21/06, Brandon Black <blblack at gmail.com> wrote:
>
>
>
> On 8/21/06, Jason Crummack <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 > > 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.08xxxseries, 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/
>
>


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


More information about the Dbix-class mailing list