My latest hypothesis is that this is a bug in fake_migrate ?? I'm using 1.99.4 on webfaction, and I'm using 1.99.7 on my development box.
When I turn on fake_migrate_all=True the .table file generated for auth_events does not match the actual table. So, I'm wondering about upgrading the version of web2py on webfaction... Does anyone have any experience with that? Is it as easy as replacing the web2py directory they created for me with the latest source and then restoring my application directories??? On Saturday, June 9, 2012 3:47:05 PM UTC-5, Brad Miller wrote: > > Well, this appears to mostly work at least using sqlite3 > > 1. change table definitions to use migrate='myprefix_tablename.table' > 2. change auth.define_tables(migrate='myprefix_') > 3. make backup of databases > 4. rename all longhashvalue_table.table to myprefix_table.table > 5. change db.py to have dal(fake_migrate_all=true) -- this seems to be a > requirement... > 6. do some stuff > 7. remove the fake_migrate_all=true > > This sequence worked perfectly on my development box using sqlite, but > when I tried a test to my staging app on webfaction which uses postgresql I > have to keep the fake_migrate_all=True or I get the following: > > <class 'psycopg2.ProgrammingError\'> column "origin" of relation > "auth_event" already exists > > grrrr!!! Any more ideas on what might be causing that?? > > Brad > > On Saturday, June 9, 2012 11:56:08 AM UTC-5, Jonathan Lundell wrote: >> >> On Jun 9, 2012, at 9:49 AM, Brad Miller wrote: >> >> in my define tables I use migrate = settings.migrate -- This made sense >> to me when I looked at migration as a global setting. But I understand now >> that its not a global setting its a filename specification for each file >> where True just means to use the hash of the connection string... >> >> So, I looked at the docs on fake_migrate. Its a bit mysterious, but >> messing around with fake_migrate got me going. >> >> But my reading of the docs make me think that I probably cannot just use >> a single value like that for migration. I now have one devdb migrate >> file... When the auth_xxxx.table I do have several new devdbauth_xxx.table >> files created for the auth tables. Note the lack of _ between devdb and >> auth. >> >> So, my guess, which I'll have to start over and verify on a clean clone, >> is that >> >> my tables should get unique values for migration such as migrate = >> 'devdb_mytable.table' >> then the value I pass to auth.define_tables should have 'devdb_' as the >> value. >> >> This makes sense to me logically at least. >> >> >> Right. I was thinking that the migrate string was prepended to the table >> name, but I guess that's not the case except for the auth tables, which >> have their own wrapper. >> >> Learning from your experience, I'm going to try to move my own auth >> migration tables to stable names, since I might well need to change my db >> password. >> >> (I do like the idea of a global migration prefix that you could set once >> and get tables of the form prefix_tablename.migrate for everything, without >> further hassle. Now all we need is a migration migration scheme...) >> >
