wmjie / ibm-db

Automatically exported from code.google.com/p/ibm-db
0 stars 0 forks source link

sqlalchemy-migrate: migrate.tests.versioning.test_schemadiff.test_float_vs_numeric fails #140

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

Running sqlalchemy-migrate tests with the DB2 10.5 patch here:

https://review.openstack.org/#/c/55572/

Fails with this:

======================================================================
FAIL: 
migrate.tests.versioning.test_schemadiff.Test_getDiffOfModelAgainstDatabase.test
_float_vs_numeric
----------------------------------------------------------------------
_StringException: Traceback (most recent call last):
  File "<string>", line 2, in test_float_vs_numeric
  File "/root/sqlalchemy-migrate/migrate/tests/fixture/database.py", line 95, in dec
    f(self, *a, **kw)
  File "/root/sqlalchemy-migrate/migrate/tests/versioning/test_schemadiff.py", line 164, in test_float_vs_numeric
    Column('data', Numeric()),
  File "/root/sqlalchemy-migrate/migrate/tests/versioning/test_schemadiff.py", line 28, in _assert_diff
    self.assertTrue(diff)
  File "/usr/lib64/python2.6/unittest.py", line 324, in failUnless
    if not expr: raise self.failureException, msg
AssertionError

What is the expected output? What do you see instead?

The test should pass since DB2 handles Numeric as a DECIMAL data type and Float 
as a FLOAT data type, but in the test they are both getting created as FLOAT 
data types.

What version of the product are you using? On what operating system?

ibm-db-2.0.4.1 (HEAD), ibm-db-sa-0.3.0 (HEAD), sqlalchemy-migrate (HEAD of 
master from stackforge/sqlalchemy-migrate), RHEL 6.4, python 2.6, sqlalchemy 
0.7.9.

Please provide any additional information below.

I see this in the code:

https://code.google.com/p/ibm-db/source/browse/ibm_db_sa/ibm_db_sa/ibm_db.py?rep
o=ibm-db-sa#88

class _IBM_Numeric_ibm_db(sa_types.Numeric):
    def result_processor(self, dialect, coltype):
        if self.asdecimal:
            return None
        else:
            return processors.to_float

So it seems that the ibm-db-sa code is converting Numeric to Float.  This is 
the change that made the above code:

https://code.google.com/p/ibm-db/source/detail?r=7b0e640e0051d7d2948262b2d6cb4f9
cb9f0af02&repo=ibm-db-sa

Original issue reported on code.google.com by mattrie...@gmail.com on 8 Nov 2013 at 7:06

GoogleCodeExporter commented 9 years ago
I'm also seeing this which seems suspect, I thought Numerics were supposed to 
be DECIMALs in DB2, not DOUBLES:

https://code.google.com/p/ibm-db/source/browse/ibm_db_sa/ibm_db_sa/base.py?repo=
ibm-db-sa#150

Original comment by mattrie...@gmail.com on 8 Nov 2013 at 7:50

GoogleCodeExporter commented 9 years ago
I think I figured out the problem.

The schemadiff code in migrate has some special logic for comparing Floats and 
in sqlalchemy, the Float type extends Numeric so that's probably why they have 
this special logic, to make sure that a column that is a Numeric is not a Float 
and vice-versa, since Float is a Numeric via inheritance.

The problem with the DB2 code is that in the ibm-db-sa driver, there is a 
DOUBLE type defined which acts like Float, it extends Numeric but it's not in 
the sqlalchemy.types code, it's only in ibm-db-sa.

So the ibm-db-sa driver converts the Float() type to DOUBLE() and the special 
logic in the migrate.versioning.schemadiff class doesn't know about it, so it 
doesn't handle it special like it does for Float and it thinks there is no 
difference, since ibm-db-sa's DOUBLE is a Numeric, which is what the test case 
is expecting it to differ on.

When I ran the test with pdb, these were the columns when it was doing the diff:

(Pdb) col_A
Column('data', Numeric(), table=<xtable>)
(Pdb) col_B
Column(u'data', DOUBLE(), table=<xtable>)
(Pdb) n

Original comment by mattrie...@gmail.com on 8 Nov 2013 at 8:08

GoogleCodeExporter commented 9 years ago
You can close this issue, I'm not sure if I'm able to, I don't see any options 
for it.

Original comment by mattrie...@gmail.com on 8 Nov 2013 at 9:04

GoogleCodeExporter commented 9 years ago

Original comment by rahul.pr...@in.ibm.com on 11 Nov 2013 at 5:48