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

[Brandon Black]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rawmode.org/pipermail/dbix-class/attachments/20060821/2d379fcd/attachment-0001.htm