alembic revision only creating an upgrade script when db changes

[Peio Roth]

Hi,

New with alembic, i'm running this awesome tool on my sqlite database.
I've imported the metadata in my env.py: alembic can then compare what's in the database (in my bd.sqlite) and what should be (in my sqa declarative models)

It works fine: when running alembic revision --autogenerate, a new upgrade script is generated in the version directory. This script contains the delta between by db model in db.sqlite and my db model at declarative level. After running the upgrade (alembic upgrade head), the two models are sync'ed.

But: when calling alembic revision --autogenerate again, alembic generates another upgrade script in the version dir. As expected, this script does nothing as db is in sync with the model. What I would like is alembic telling me that there was nothing to do or even better not creating any upgrade script (passing an option ?).

Why ? My continuous integration tool pulls the latest commits and builds a db with it. I would like to integrate alembic upgrade scripts generation to it but I do not want to get one 'do nothing' script everytime a build is fired. I would like alembic step to generate a script only when changes in my sqa models occured.

Any idea?

Thanks!

[Michael Bayer]

Why ? My continuous integration tool pulls the latest commits and builds a db with it. I would like to integrate alembic upgrade scripts generation to it but I do not want to get one 'do nothing' script everytime a build is fired. I would like alembic step to generate a script only when changes in my sqa models occurred.

we have someone who requested this feature here: https://bitbucket.org/zzzeek/alembic/issue/80/autogenerate-should-have-an-option-to-skip .

I'm not strongly opposed to a flag for this, but at the same time I think the desire for this flag is misplaced.   The --autogenerate feature isn't intended to ever be used in "handsfree" mode, it only catches a subset of the possible kinds of migrations, and even then it frequently needs additional help with those migrations that it did catch.    Relying upon auto generate to catch every possible change to a schema without any developer intervention won't work.  It won't detect things like changes in foreign key, unique, or check constraints, it won't detect index changes (though that one I need to fix soon), it won't detect column or table renames, it won't detect changes in column types, or server defaults.    It's also tricky when using custom types, as you need to make sure those custom types have a __repr__() that works acceptably, so if you were to add a new table with a new type it would very likely not work correctly on the first --autogenerate run.

So when I use Alembic with --autogenerate, it's great, but theres no way in the world I'd ever run it and then not carefully comb through the file it creates, and if the file it creates is blank, I know that's wrong, because I only run --autogenerate when I, the developer, have changed something in the code that I know changes the schema.

So the user that requested this feature, he wants to be able to run it anyway as a means of "catching" schema changes.   Even though I've said that's not reliable, he's OK with it.  OK, I'm not opposed to the flag for people who really want to do it that way.

But then in this case, it sounds like you're looking to run "alembic revision --autogenerate" within….an automated build on continuous integration ?   That seems very unusual to me - it implies that either you aren't maintaining your revision files in source control (which is not at all how Alembic was designed to be used, I'm not sure how that would even work) or your continuous integration system is going to check in new source files (which is not at all how continuous integration is designed to be used, I'm not sure how that would work either).

If that's not what you mean, and you only mean that you don't want blank upgrade files as you develop your app, sure we can add the flag at some point (pull req would be nice), but really the vast majority of users have no need for such a flag, because it's easy enough to only run --autogenerate when one has actually made a schema change, and a blank revision file does not in any way mean nothing has changed.

[Peio Roth]

Le mardi 19 février 2013 16:44:29 UTC+1, Michael Bayer a écrit :

If that's not what you mean, and you only mean that you don't want blank upgrade files as you develop your app, sure we can add the flag at some point (pull req would be nice), but really the vast majority of users have no need for such a flag, because it's easy enough to only run --autogenerate when one has actually made a schema change, and a blank revision file does not in any way mean nothing has changed.

 

You're absolutely right. I though I could try to set up some automation at this point but db migration has to be handled carefully and I agree with you : the developer who made the change can run an alembic revision --autogenerate and check that the generated upgrade script does not need further tuning.

Conclusion: I can live without this flag ;-)

Thanks for your time Michael.