Oracle autoload broken because of LONG_STRING

Following table will fail to be auto loaded using the trunk with Oracle 10g

CREATE TABLE Z_TEST
(
  ID        NUMBER(22) PRIMARY KEY,
  ADD_USER  VARCHAR2(20)  DEFAULT USER NOT NULL
)

It fails with:

>>> from sqlalchemy import *
>>> meta = BoundMetaData('oracle://scott:tiger@test_db')
>>> tbl = Table('z_test', meta, autoload=True)
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "c:\gnu\src\sqlalchemy\lib\sqlalchemy\schema.py", line 162, in __call__
    metadata.get_engine().reflecttable(table)
  File "c:\gnu\src\sqlalchemy\lib\sqlalchemy\engine\base.py", line 869, in reflecttable
    self.dialect.reflecttable(conn, table)
  File "c:\gnu\src\sqlalchemy\lib\sqlalchemy\databases\oracle.py", line 340, in reflecttable
    row = c.fetchone()
  File "c:\gnu\src\sqlalchemy\lib\sqlalchemy\engine\base.py", line 1097, in fetchone
    return self._process_row(row)
  File "c:\gnu\src\sqlalchemy\lib\sqlalchemy\engine\base.py", line 1182, in _process_row
    row = [i) for i in xrange(len(row))](sup._get_col(row,)
  File "c:\gnu\src\sqlalchemy\lib\sqlalchemy\engine\base.py", line 1066, in _get_col
    return rec[1](1).convert_result_value(row[rec[2](rec[2)], self.dialect)
  File "c:\gnu\src\sqlalchemy\lib\sqlalchemy\databases\oracle.py", line 99, in convert_result_value
    return value.read()
AttributeError: 'str' object has no attribute 'read'
>>>

From what I can tell ALL_TAB_COLUMNS view returns LONG as datatype for DATA_DEFAULT column. LONG is being classified as a OracleBinary according to source:/sqlalchemy/trunk/lib/sqlalchemy/databases/oracle.py line 194

        if self.dbapi is not None:
            self.ORACLE_BINARY_TYPES = [k) for k in ["BFILE", "CLOB", "NCLOB", "BLOB", "LONG_BINARY", "LONG_STRING"](getattr(self.dbapi,) if hasattr(self.dbapi, k)]
        else:
            self.ORACLE_BINARY_TYPES = []

Finally autodiscovery fails when value for the string is being read(). The quick fix was to remove "LONG_STRING" from the list of binary types but that is probably not the right solution.

It looks like the check was introduced during ~~#435~~

Comments (5)