I have ran into this problem serveral times when the password changes in
the connection string.

All you have to do:
db = DAL('...', fake_migrate=True)
auth.define_tables(fake_migrate=True)

This will recreate all the HASH in the databases folder and not change your
database. Once you run the code once you can go back and remove the
fake_migrate=True from both off the above.

--
Regards,
Bruce

On Sat, Jun 9, 2012 at 9:56 AM, Jonathan Lundell <[email protected]> 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...)
>



-- 
-- 
Regards,
Bruce Wade
http://ca.linkedin.com/in/brucelwade
http://www.wadecybertech.com
http://www.fittraineronline.com - Fitness Personal Trainers Online
http://www.warplydesigned.com

Reply via email to