while developing you should NOT use any of the migrate, fake_migrate, migrate_enabled, etc. Zero tickets in regards of db migrations (unless you do something weird like trying to change a column type from string to integer).
The minute you go on production, deploy the app, hit the appadmin page (so all tables are created on your fresh "production" db), return to the db.py file and set migrate=False on the DAL. Next iteration, you develop another piece of app, freeze it, update your production, set migrate=True on the DAL, re-hit the appadmin page, return to db.py and set migrate=False. Next iteration, you screw some table (like converting a string column to an integer), the previous working method will NOT work (mostly because only you can know how to migrate that column (others call it "fixtures"....e.g. attempt a conversion and NULL all fields that doesn't cast to integers vs drop the column and readd and fill with default values, etc, etc, etc)). It's time to: - manually alter the database (optionally applying your fixtures) so that the db reflects your model - update your app - optional step: set fake_migrate_all=True in the DAL, hit the appadmin page (so .table files are recreated) and reset fake_migrate_all to False - set migrate=False on the DAL - use you app Didn't have ANY problems with this line of work in 2 years of deployment. --
