Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Computed column migration file generated incorrectly #624
SQLAlchemy version 1.3.11 (just released on November 11th, 2019) includes support for Computed columns. From their documentation an example Computed column definition would be something like:
After adding such a Computed column definition to my table model and trying to use alembic to autogenerate a migration file I encounter the following error:
I found that that if I hacked in a str() implementation to the Computed class definition in SQLAlchemy I was able to use alembic successfully however I'm not sure if that's the most elegant solution.
I'm using alembic version 1.3.0, sqlalchemy 1.3.11 (and MySQL 8.0.17 although I don't believe that matters as far as this issue is concerned).
I really appreciate any help or suggestions!
I am in need of a quick dirty fix, so I made one. Might me usefull for somebody :)
in alembic/autogenerate/render.py edit:
OK...usually we start with the "render only" model, that is, if someone has computed columns in their Table metadata and they just generate a plain create_table(), the computed shows up. that's the basic level of functionality. I'm assuming that you don't see any issue with this part proceeding.
the next level is support of changes in "computed", which has to do with reading the table columns in the DB and reading them in the model and comparing, and I'm assuming this is what you're referring towards. we don't implement this feature for CHECK constraints either right now as well as for expression-based indexes and lots of other things. this is not a critical feature though, it only means that we aren't detecting if someone changed the expression in their computed column. we would need to support ALTER COLUMN that changes that for each target DB also.
it seems that currently sqlalchemy when inspecting a computed column sets the server default to the normal text of the generated alwayas,
-- table in db create table foo ( bar indeger, foo integer GENERATED ALWAYS AS (bar + 1) STORED ) -- is inspected as create table foo ( bar indeger, foo integer DEFAULT (bar + 1) )
I've just tried mysql and it does not have this behavior