793f4b7c71
This patch removes code that was causing the SQLAlchemy BigInteger type to render as INTEGER on the SQLite backend only. The comment in create_shadow_table() in nova/db/sqlalchemy/utils.py which states that BigInteger isn't supported by SQLite is not correct. SQLite has an "affinity"-based, dynamic typing model [1] that allows virtually any name to be used for a type; datatypes are actually determined on a row-by-row basis, but any type name that has the substring INT inside of it is automatically given integer affinity by default, so there is no limitation on this type. There is one difference on SQLite between INTEGER and BIGINT, and that is that SQLite's "rowid" feature only takes effect for a primary key column if it is named "INTEGER PRIMARY KEY" [2]. However, as all tests pass here it does not seem to be the case that we are using BigInteger primary keys in tests, and if we were, I'd rather approach SQLite's quirk here in a different way. Note that this patch relies upon the assumption that **SQLite is only used in Nova as a test database, not in actual deployments**. If this statement is not true, then information on these other use cases will be needed. Due to Alembic issue #341 [3] which has been resolved for version 0.8.4 [4], the comparison of INTEGER/BIGINT/SMALLINT is now significant by default, so this change (or alternatively, one that changes Nova's type comparison rules within migration tests) is needed in order for Nova to pass the test_migrations test; the error condition that raises with the latest Alembic is shown in [5]. [1] http://sqlite.org/datatype3.html [2] http://sqlite.org/lang_createtable.html#rowid [3] https://bitbucket.org/zzzeek/alembic/issues/341/integer-vs-biginteger-diffrence-are-not [4] http://alembic.readthedocs.org/en/latest/changelog.html#change-f8a974100f54b74d7f90ef765edae1ed [5] http://paste.openstack.org/show/480966/ Change-Id: I05469578a748a33fdf3c0aa5a5fee1bbe69b94cd
0 lines
Python
0 lines
Python