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]<javascript:> > > 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 [email protected] <javascript:>. >> 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.
