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