I think I said it at least 5 times (and there's the book <http://web2py.com/books/default/chapter/29/06/the-database-abstraction-layer#Migration-control-summary>). Each option has its own environment. And everything follows a logic.
A) migrate on DAL sets a default for migrate for all tables (i.e. migrate on table wins) B) migrate_enabled=False on DAL sets migrate=False for all tables, EVEN for tables with migrate=True (i.e. migrate_enabled=False wins over migrate=True on tables) C) fake_migrate on tables enables fake migrations for tables with migrate=True (i.e. migrate=False and fake_migrate=True doesn't enable fake migrations) D) fake_migrate_all sets fake_migrate=True on all tables that being said, usual rules apply. - In production, don't waste CPU on migrations. Either set migrate=False on all tables, or migrate=False on DAL, or don't explicitly define migrate for both DAL and table and set migrate_enabled=False as a failsafe. - no need ever to fake_migrate, unless, in a development history with version 1-->2-->3 of a table, you migrated manually from 1 to 2 and want web2py to migrate automatically to 3 (meaning: to sync the version 2 of the model with the hand-made change on the backend you fake_migrate it, and then you can let web2py migrate from 2 to 3) If you come up with a different clean database, to let the app create all tables, you need to let tables migrate. It means that you need to: - check that no table has explicit migrate=False - set migrate=True on DAL (that overrides the default for each table) - hit appadmin once - re-disable migrations If you come up with a new table (or a new column on an existing table): - check that that table has explicit migrate=True - leave migrate=False on DAL (that ovverrides the default for each table, minus the one you want to migrate) - hit appadmin once - remove the explicit migrate=True from the table etc etc etc On Monday, September 5, 2016 at 11:27:01 PM UTC+2, Ron Chatterjee wrote: > > migrate_enabled = false > migrate = false > fake_migrate = false > fake_migrate_all = false > > > These settings are only if we don't need to update the database and use > the current database. We can use these settings in the deploy mode. Am I > correct? In other words, if I delete the entire database and reinstall the > app, all these flags needs to be true. Isnt? What if in the case that we > have a new table and we want to keep rest of the database intact? sought of > in between. > > On Monday, September 5, 2016 at 11:25:12 AM UTC-4, Scott Hunter wrote: >> >> I found the problem; migrations weren't being disabled because, while I >> had the correct settings in appconfig.ini, they were not being used >> properly in creating the db object. >> >> - Scott >> >> On Saturday, September 3, 2016 at 1:01:39 PM UTC-4, Scott Hunter wrote: >>> >>> I have an app which runs *much* slower than expected on pythonanywhere. >>> >>> I enabled the profiler, and one thing stood out: on pythonanywhere, the >>> function the most time was spent in, by far, is fcntl.flock from inside >>> portalocker while loading the models. In fact, when run locally, >>> portalocker isn't even being called: it goes straight from save_dbt to >>> cPickle.dump. >>> >>> Is there some configuration specific to web2py that might address this, >>> or is it something I should take up w/ the people at PA? >>> >>> - Scott >>> >> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
