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. Brad On Saturday, June 9, 2012 11:34:11 AM UTC-5, Jonathan Lundell wrote: > > On Jun 9, 2012, at 8:55 AM, Brad Miller wrote: > > Thanks Jonathan, > > I did not realize that migrate could be anything other than True or False! > > I did some experimenting on my development application as follows: > > I changed settings.migrate = 'devdb' > > then in the databases directory I renamed all the *.table files so that > the old hash value was replaced with devdb. So now I have > devdb_auth_user.table ... devdb_courses.table etc. > > Unfortunately when I restart my app and try to do anything I get the table > already defined error. > > Is that what you suggested I do? > > > settings.migrate is only going to be effect when you run the admin wizard. > Did you do that? > > Otherwise, you need to set migrate in your define_table calls as well as > auth.define_tables. >
