cx_Oracle.CLOB compares as true to cx_Oracle.STRING, NATIVE_FLOAT == NUMBER in git master

[zzzeek]

Hi there -

Reviewing our CI that tests against cx_Oracle master I have a few more things coming in.

The first is that the comparison behavior of cx_Oracle.CLOB seems to have changed. We have an outputtype handler that does logic like this:

if default_type in (cx_Oracle.STRING, cx_Oracle.FIXED_CHAR):
    # do something for strings
elif default_type in (cx_Oracle.CLOB, cx_Oracle.NCLOB):
   # do something for clobs

current cx_Oracle master vs. the released version of cx_Oracle 7.3.0 has changed the behavior of CLOB such that the above code no longer works as expected:

Python 3.7.6 (default, Jan 30 2020, 09:44:41) 
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cx_Oracle
>>> cx_Oracle.__version__
'8.0.0-dev'
>>> cx_Oracle.CLOB == cx_Oracle.STRING
True

compare to current relased version 7.3.0:

Python 3.7.6 (default, Jan 30 2020, 09:44:41) 
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cx_Oracle
>>> cx_Oracle.__version__
'7.3.0'
>>> cx_Oracle.CLOB == cx_Oracle.STRING
False

is this change in behavior intentional ?

[zzzeek]

OK similar issue with numbers, this is also warranting a change in our outputtypehandler for NATIVE_FLOAT (in cx_oracle 8 this appears to be a synonym for a new DB_TYPE_BINARY_DOUBLE) vs. NUMBER:

Python 3.7.6 (default, Jan 30 2020, 09:44:41) 
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cx_Oracle
>>> cx_Oracle.__version__
'8.0.0-dev'
>>> cx_Oracle.NATIVE_FLOAT == cx_Oracle.NUMBER
True
>>> 
[classic@photon3 sqlalchemy]$ python
Python 3.7.6 (default, Jan 30 2020, 09:44:41) 
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cx_Oracle
>>> cx_Oracle.__version__
'7.3.0'
>>> cx_Oracle.NATIVE_FLOAT == cx_Oracle.NUMBER
False

I can work around these things by adjusting my comparison logic but just putting it out there that this is a behavioral change.

[anthony-tuininga]

Yes, it is a behavior change and was intentional based on the DB API which says this about STRING: This type object is used to describe columns in a database that are string-based (e.g. CHAR). REF. The suggested implementation notes suggest that the behavior now in cx_Oracle is "correct" REF. Similar comments apply to NUMBER.

So you would need to use the more specific types (DB_TYPE_*) if you need to do something with those specific types. The DB API types are intended to be very generic as far as I can tell.

That said, I'd appreciate feedback. You can see which types match equal by looking at this code. Comments definitely welcome!

[zzzeek]

these two kinds of types historically behave very differently, CLOB at least returns that LOB object which is totally different from string, and in the FLOAT / NUMBER area I'm likely dealing with Decimal / float return type issues. that said, this is all happening in an outputtypehandler that is already highly modifying cx_Oracle's default behaviors and we've adjusted for this change, so other than being aware that other folks might be surprised by this, onwards!

[anthony-tuininga]

Hmm, based on your comments I agree that CLOB, BLOB, BFILE and NCLOB are all different sort of beasts and probably shouldn't match equal to STRING and BINARY. So I think I'll remove that equality. The rest make sense, I think!