Variant base not taken into account when comparing types #433
Comments
Michael Bayer (@zzzeek) wrote: seeing that failure against SQLite or against other backends? current observation is the SQLite comparison will succeed because it compares only Integer. There seems to be a problem with the BigInteger() part of it, however, e.g. on other backends. |
Changes by Michael Bayer (@zzzeek):
|
Changes by Michael Bayer (@zzzeek):
|
Changes by Michael Bayer (@zzzeek):
|
Michael Bayer (@zzzeek) wrote: even though we do dialect_impl() in the comparison, apparently for Variant if you are on a default dialect it gives you back itself (because it's a TypeDecorator). need to adjust for this. |
Michael Bayer (@zzzeek) wrote: |
Michael Bayer (@zzzeek) wrote: Adjust for Variant returning itself as impl Fixed bug where autogen comparison of a :class: Change-Id: Ie94779ece9f1c768375cdbdc4124c98f9c11bb86 → 54c5abb |
Changes by Michael Bayer (@zzzeek):
|
Dheeraj Gupta wrote: @zzzeek Yes you are correct....tests succeed for SQLite backend but fail for MySQL backend. Thanks for the quick-fix. |
Migrated issue, originally created by Dheeraj Gupta
I have a set of migration tests for my model which has a lot of autoincrement primary keys not all of which are Integer.
To support sqlite, my models have id lines like so
I use alembic for migrations and have written tests which compare the types of columns too. For versions of alembic <= 0.8.3, all tests pass. However, for versions newer than 0.8.4, I get the following differences from metadata (leading to test failure)
I understand that Issue 341 had added additional type comparison and this change probably broke my tests.
Is it possible to fine-tune type checking for variants or should I just rework my tests to ignore such differences?
The text was updated successfully, but these errors were encountered: