when I upgrade, I copy over the database/* files (just in case for extra-urgent simple migrations), but I keep migrate=False on all tables. Running the first request with the database/* folder empty and fake_migrate in all tables (or fake_migrate_all in the DAL) will just recreate the .table files. There's nothing wrong (if you plan to manage migrations *outside* web2py) to work with migrate=False on all tables (or migrate_enabled=False on the DAL line) without any database/* files. In any case, try it out with a dev version, I don't wanna be held responsible :P
PS: watch out the auth.define_tables(), it defaults on migrate=True and fake_migrate=False on its own (so tune the parameters accordingly) On Tuesday, March 19, 2013 7:16:13 PM UTC+1, Jonathan Lundell wrote: > > I've got a web2py app that serves as the back end for an iPad app > (Watchup, if you're interested; try it, it's free and useful). It's > currently running on a pair of Rackspace servers running RHEL6, one for > web2py, one for MySQL. I've been running an older version of web2py (~2.0 > IIRC) for quite a while, and it's time to upgrade. > > In doing so, I'd like to upgrade the virtual server itself, RHEL6, and > some associated packages in addition to bringing web2py up to date. > > When I first deployed all this, I developed a fabfile that lets me build a > server from scratch, painlessly, so that's what I'll be doing. > > My question is: what's the best way to connect the new installation to the > existing database (running on its own server, remember). It seems to me > that I have two options: > > 1. Copy the databases/ directory from the old server, or > > 2. Run the new server initially with fake_migrate. > > Will either work? Is there any reason to prefer one over the other? And is > there some third alternative I'm not thinking of? > > Anything else I should worry about? -- --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
