Describe the bug
After a table is created with a primary key, if that key is updated to have a comment (or presumably any other change) the resulting migration drops nullable=False, generating a sql command like: ALTER TABLE key_and_nullable MODIFY id INTEGER(11) NULL AUTO_INCREMENT COMMENT 'auto-incrementing key';
This occurs even if the column had nullable set explicitly.
Expected behavior
The generated migration should have nullable=False for autoincrementing columns (or at least for primary keys).
The generated SQL should be: ALTER TABLE key_and_nullable MODIFY id INTEGER(11) NOT NULL AUTO_INCREMENT COMMENT 'auto-incrementing key';
To Reproduce
Repo with a minimal example. In particular the second migration and the generated SQL as linked above.
Versions.
- OS: Debian GNU/Linux rodete (x86-64)
- Python: 3.8.6
- Alembic: 1.4.3
- SQLAlchemy: 1.3.22
- Database: mysql Ver 15.1 Distrib 10.5.8-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper
- DBAPI: mysql
Additional context
This migration (both through alembic and running as the raw SQL) seems to run without any problem in my local environment and does not actually change the key to be nullable, but in my work dev environment, running the SQL errors out, which seems reasonable, a primary key shouldn't be nullable. I'm not sure what's different about the dev environment without further investigation, but this really should be generated as not nullable anyway.
Describe the bug
After a table is created with a primary key, if that key is updated to have a comment (or presumably any other change) the resulting migration drops
nullable=False, generating a sql command like:ALTER TABLE key_and_nullable MODIFY id INTEGER(11) NULL AUTO_INCREMENT COMMENT 'auto-incrementing key';This occurs even if the column had nullable set explicitly.
Expected behavior
The generated migration should have
nullable=Falsefor autoincrementing columns (or at least for primary keys).The generated SQL should be:
ALTER TABLE key_and_nullable MODIFY id INTEGER(11) NOT NULL AUTO_INCREMENT COMMENT 'auto-incrementing key';To Reproduce
Repo with a minimal example. In particular the second migration and the generated SQL as linked above.
Versions.
Additional context
This migration (both through alembic and running as the raw SQL) seems to run without any problem in my local environment and does not actually change the key to be nullable, but in my work dev environment, running the SQL errors out, which seems reasonable, a primary key shouldn't be nullable. I'm not sure what's different about the dev environment without further investigation, but this really should be generated as not nullable anyway.