Niphlod, Thanks for all that information. I was getting issues with more than just auth tables so had to take a different approach.
I carried out roughly the steps which I described above, and am happy to report it is all working perfectly! Regarding PS3, I thought migration only happened when you refreshed the Data Admin page. Are you telling me that the migration check occurs on every request? I always have a mirror copy of the live application pointing to the same database for development. I take it it's best practice for the live application that takes all the real user requests to have migrate_enabled=False, and only keep it on in the development one in that case... Thanks, Andrew. On Tue, Feb 5, 2013 at 1:10 PM, Niphlod <[email protected]> wrote: > I guess simply disabling migration on auth will work, e.g. > auth.define_table(migrate=False) > > PS: if migrations are fired it means that the .table files are out of sync > with your current model. > > PS2: if you're totally sure that your current model is in sync with the > database (hence the only things out of sync are the table files) you should > use fake_migrate, let it on for a single request (given you're not using > lazy_tables, a single request will recreate the .table files) and then turn > fake_migrate off. > > PS3: if you know for sure that the model doesn't change keeping migration > on it's just a relatively big performance penalty. That being said, it's > useful to let models in sync with table files, so at the following model > change you just have to turn them on for a single request, see the > migration happening and then turn migrations off. > > > On Tuesday, February 5, 2013 1:51:56 PM UTC+1, Andrew Buchan wrote: > >> Tim, >> >> I had tried with various permutations of migrate and fake_migrate on the >> tables and in the top level db definition, but it kept timing out/freezing. >> I now managed to get it to work using only migrate_enabled=False at the >> db definition. >> >> The thing is, I want migration enabled. That's one of the key things I >> like about web2py... However if I set fake_migrate_all=True and reload data >> Admin, it freezes and I have to restart the server again... >> >> I know that the database tables match the definitions, because it all >> work with migration enabled in the previous version. All I want is to be >> able to upgrade web2py to the latest version and keep the migration enabled >> behaviour. >> >> Unless I find a way of achieving this within web2py, I think I'll try the >> following: >> >> 1. Rename the live database. >> 2. Create temporary blank database with old name of live database. >> 3. Point the DAL files running from version 2.3.2 to that database with >> migrate enabled, so it creates the tables and accordingly the .table files >> (using the hash generated from the connection string in the file names). >> 4. Delete temp database. >> 5. Rename live database back to old name. >> 6. Pray that I get no issues when I reload Data Admin :-) >> >> I'll report back with how that works, unless anyone can suggest a smarter >> way in the meantime. (I know I could use a blank db with another name, and >> rename the .table files to reuse the hash from the connection string to >> live, I'll see...) >> >> >> >> >> >> >> >> >> On Tue, Feb 5, 2013 at 10:55 AM, Tim Richardson >> <[email protected]>wrote: >> >>> >>> It seems that the newer version of web2py deemed there were some >>>> differences between how the table is defined in the web2py model file and >>>> how it i >>>> >>>> Did the DAL migrate functionality change significantly between version >>>> 1.93.2 and 2.3.2? >>>> Can anyone advise? >>>> >>>> many thanks, >>>> >>>> Andrew. >>>> >>> >>> I use windows and MSSQL but just beginning, so I'm curious to know: why >>> not disable migration? >>> >>> -- >>> >>> --- >>> 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+un...@**googlegroups.com. >>> >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>> . >>> >>> >>> >> >> -- > > --- > 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. > > > -- --- 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.
