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...) >
