Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integer vs BigInteger diffrence are not checked #341

Closed
sqlalchemy-bot opened this issue Dec 5, 2015 · 6 comments
Closed

Integer vs BigInteger diffrence are not checked #341

sqlalchemy-bot opened this issue Dec 5, 2015 · 6 comments

Comments

@sqlalchemy-bot
Copy link

@sqlalchemy-bot sqlalchemy-bot commented Dec 5, 2015

Migrated issue, originally created by akamyshnikova (@akamyshnikova)

I have a model

class Test(model_base.BASEV2):
    name = sa.Column(sa.String(255), primary_key=True)
    test = sa.Column(sa.Integer())
    test2 = sa.Column(sa.BigInteger())

And a migration script

def upgrade():
    op.create_table('tests',
    sa.Column('name', sa.String(length=255), nullable=False),
    sa.Column('test', sa.Integer(), nullable=True),
    sa.Column('test2', sa.Integer(), nullable=True),
    sa.PrimaryKeyConstraint('name'),
    )

If I run

alembic revision -m 'test' --autogereate

to check such changes, new script migration is not created and difference between Integer and BigInteger is not detected.

alembic  revision -m 'test2' --autogenerate
  Running revision  ...
INFO  [alembic.runtime.migration] Context impl MySQLImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
  OK

Note, that changes between Integer and String are checked.
Alembic version '0.8.3'

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Dec 5, 2015

Changes by akamyshnikova (@akamyshnikova):

  • edited description
@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Dec 5, 2015

Michael Bayer (@zzzeek) wrote:

this is currently expected behavior because the default type comparison logic is intentionally very conservative, so as not to produce false positives. Otherwise, if the model contains Integer, and the database contains mysql.INTEGER, these are not actually the "same" type; INTEGER is much more specific. So the comparison is done using "type affinity" alone, and in SQLAlchemy a BigInteger and Integer, as well as all their descendant types, have the same affinity.

However, there are two specific comparator functions _string_compare and _numeric_compare that are added to grant more specificity to these types, so in the case of Integer we can add one of these.

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Dec 5, 2015

Michael Bayer (@zzzeek) wrote:

  • Added a type-level comparator that distinguishes :class:.Integer,
    :class:.BigInteger, and :class:.SmallInteger types and
    dialect-specific types; these all have "Integer" affinity so previously
    all compared as the same.
    fixes #341

98a0e3f

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Dec 5, 2015

Changes by Michael Bayer (@zzzeek):

  • changed status to closed
@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Dec 5, 2015

Michael Bayer (@zzzeek) wrote:

thanks for reporting!

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Dec 6, 2015

Michael Bayer (@zzzeek) wrote:

sigh. it broke Nova: https://review.openstack.org/#/c/253859/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.