Issues

Issue #2987 resolved

create oracle.DATE type; have it subclass sqltypes.DateTime

William Edwards
created an issue

If you load an Oracle table (using cx_Oracle) via MetaData.reflect, Oracle DATE columns have the sqlalchemy.sql.sqltypes.DATE type.

However, Oracle DATE columns have time components, and should be mapped to sqlalchemy.sql.sqltypes.DATETIME.

Comments (10)

  1. William Edwards reporter

    That's the point: the Oracle DATE column is equivalent to DateTime in Python; it has a time component.

    When you load an Oracle table using MetaData.reflect, however, you get told its a Python Date column. This is the bug.

  2. Mike Bayer repo owner

    The SQLAlchemy DATE type does nothing, it's just a marker. The DBAPI passes the date or datetime values right through and a similar thing happens on the result side.

    So as far as "bug", it's still not clear to me what your program actually needs to accomplish for which this behavior causes it to fail.

    the convention of UPPERCASE type objects is that they must match exactly. So at best, we'd make an oracle DATE type that happens to subclass sqltypes.DateTime. It cannot refer to sqltypes.DATETIME because that type does not exist on oracle.

    However, this would also be backwards-incompatible for the very unlikely case that apps are relying upon the very few features that DATE/DATETIME provide, like "python_type" or the seldom-used expression adaptations of the + or - operators, that's pretty much it.

    But since you're reporting this as a bug, I'm guessing that maybe you actually are using python_type. But I really hate having to guess so please elaborate on what the actual problem is, thanks.

  3. William Edwards reporter

    I ran into this bug trying to use the same table statements across several db backends.

    I'll write up some simple reproduction code for you at work tomorrow.

  4. Mike Bayer repo owner

    no need, I get it, just wanted to know what use case you were doing.

    I'm a little antsy about doing this in the middle of a series, I'd need to decide that this isn't going to pull the rug from anyone relying on the current behavior, but I will probably just do it (0.9 only though).

  5. Mike Bayer repo owner
    • Added new datatype :class:.oracle.DATE, which is a subclass of :class:.DateTime. As Oracle has no "datetime" type per se, it instead has only DATE, it is appropriate here that the DATE type as present in the Oracle dialect be an instance of :class:.DateTime. This issue doesn't change anything as far as the behavior of the type, as data conversion is handled by the DBAPI in any case, however the improved subclass layout will help the use cases of inspecting types for cross-database compatibility. Also removed uppercase DATETIME from the Oracle dialect as this type isn't functional in that context. fixes #2987

    → <<cset be3c185fd48c>>

  6. Log in to comment