Variant base not taken into account when comparing types

Issue #433 resolved
Dheeraj Gupta
created an issue

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

id_ = Column("id", BigInteger().with_variant(Integer, "sqlite"),
                 primary_key=True)

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)

[('modify_type', None, 'ip_checkpoint', 'id', {'existing_server_default': False, 'existing_nullable': None}, BIGINT(display_width=20), Variant())]

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?

Comments (6)

  1. Michael Bayer repo owner

    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.

  2. Michael Bayer repo owner

    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.

  3. Michael Bayer repo owner

    Adjust for Variant returning itself as impl

    Fixed bug where autogen comparison of a :class:.Variant datatype would not compare to the dialect level type for the "default" implementation of the :class:.Variant, returning the type as changed between database and table metadata.

    Change-Id: Ie94779ece9f1c768375cdbdc4124c98f9c11bb86 Fixes: #433

    → <<cset 54c5abb15cae>>

  4. Log in to comment