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?

More or less. But I'm not entirely sure under what circumstances web2py's 
migration logic tries to create tables, so this might not be the whole story, 
and your migration files might be out of sync with the database for some reason.

You might want to read the book sections about fake_migrate, an option that 
rebuilds the migration files by looking at the database, now that you have 
stable migration file naming. You can do it one table at a time, in 
define_table, or for the whole database, in DAL(). 

(I had a vaguely similar problem recently, in which I was inadvertently 
switching between MySQL and SQLite. Confusing.)

> 
> Thanks,
> 
> Brad
> 
> On Saturday, June 9, 2012 10:23:22 AM UTC-5, Jonathan Lundell wrote:
> On Jun 9, 2012, at 7:48 AM, Brad Miller wrote:
>> webfaction has a control panel, and I used their control panel to change the 
>> password.  It was the same mechanism I used to set up the database in the 
>> first place.  The only difference, of course, is that when I first set it up 
>> there were not any tables.  I don't know what they do behind the scenes when 
>> updating a password.
>> 
>> To me the most important question is how do I recover.  Right now I'm in a 
>> very undesirable state, where I have to have migrate=False in order for my 
>> application to work.  Any suggestions??
> 
> Massimo, Brad is talking about the database password, not the web2py admin 
> password.
> 
> Brad, the migration file prefix is a hash of the database connection string 
> (URL), which in your case includes the password. Your idea of renaming the 
> migration files sounds promising.
> 
> To avoid this in the future, assign your own prefix to the migration files by 
> using migrate='somestring' instead of migrate=True. Of course, doing so in 
> midstream will cause yet another renaming, so in advance you could copy all 
> your migration files to the new name and then restart, and finally remove the 
> old ones.
> 
> I think. 
> 
> 
>> 
>> Thanks
>> 
>> Brad
>> 
>> On Saturday, June 9, 2012 9:44:58 AM UTC-5, Massimo Di Pierro wrote:
>> You can change password outside of admin but need to hash it first. How did 
>> you change it?
>> 
>> 
>> 
>> On Saturday, 9 June 2012 09:22:02 UTC-5, Brad Miller wrote:
>> Hi,
>> 
>> Here's what happened.  I'm hosting a web2py application on webfaction 
>> (http://interactivepython.org)
>> 
>> This morning, after some maintenance I had tested everything and all was 
>> good.  Pages were working login/logout was working, database access was 
>> working perfectly.  Then, because I realized I had stupidly stored my 
>> password to the database (Postgresql) out on github, I went to the 
>> webfaction dashboard and changed the password for my database.  I dutifully 
>> made the same change in my configuration file and restarted.  Thats when 
>> everything came crashing down around me.
>> 
>> I was getting the dreaded table already exists error on every request.  
>> Changing migrate to false seemed to alleviate the problem, except for two 
>> tables where I had not explicitly set migrate to the value in my settings.
>> 
>> A little searching through this group is overwhelming in the number of 
>> others this seems to effect at various times.
>> 
>> So, my question is what happened?  My hypothesis is that changing the 
>> password outside of the web2py admin is a no no.  :-(  I haven't figure out 
>> how to configure webfaction to allow me admin access.
>> 
>> After dropping a couple of the tables that don't have important data in 
>> them, I noticed that the prefix on the .table file in the databases 
>> directory was different from all the others.  So, did changing the password 
>> cause the UUID to change?  If so, can I recover, and put migrate back to 
>> True by renaming all my .table files using the newer prefix?
>> Is there a better way to get things synced up so I could potentially make a 
>> schema change?
>> 
>> Thanks,
>> 
>> Brad
> 
> 
> 
> On Saturday, June 9, 2012 10:23:22 AM UTC-5, Jonathan Lundell wrote:
> On Jun 9, 2012, at 7:48 AM, Brad Miller wrote:
>> webfaction has a control panel, and I used their control panel to change the 
>> password.  It was the same mechanism I used to set up the database in the 
>> first place.  The only difference, of course, is that when I first set it up 
>> there were not any tables.  I don't know what they do behind the scenes when 
>> updating a password.
>> 
>> To me the most important question is how do I recover.  Right now I'm in a 
>> very undesirable state, where I have to have migrate=False in order for my 
>> application to work.  Any suggestions??
> 
> Massimo, Brad is talking about the database password, not the web2py admin 
> password.
> 
> Brad, the migration file prefix is a hash of the database connection string 
> (URL), which in your case includes the password. Your idea of renaming the 
> migration files sounds promising.
> 
> To avoid this in the future, assign your own prefix to the migration files by 
> using migrate='somestring' instead of migrate=True. Of course, doing so in 
> midstream will cause yet another renaming, so in advance you could copy all 
> your migration files to the new name and then restart, and finally remove the 
> old ones.
> 
> I think. 
> 
> 
>> 
>> Thanks
>> 
>> Brad
>> 
>> On Saturday, June 9, 2012 9:44:58 AM UTC-5, Massimo Di Pierro wrote:
>> You can change password outside of admin but need to hash it first. How did 
>> you change it?
>> 
>> 
>> 
>> On Saturday, 9 June 2012 09:22:02 UTC-5, Brad Miller wrote:
>> Hi,
>> 
>> Here's what happened.  I'm hosting a web2py application on webfaction 
>> (http://interactivepython.org)
>> 
>> This morning, after some maintenance I had tested everything and all was 
>> good.  Pages were working login/logout was working, database access was 
>> working perfectly.  Then, because I realized I had stupidly stored my 
>> password to the database (Postgresql) out on github, I went to the 
>> webfaction dashboard and changed the password for my database.  I dutifully 
>> made the same change in my configuration file and restarted.  Thats when 
>> everything came crashing down around me.
>> 
>> I was getting the dreaded table already exists error on every request.  
>> Changing migrate to false seemed to alleviate the problem, except for two 
>> tables where I had not explicitly set migrate to the value in my settings.
>> 
>> A little searching through this group is overwhelming in the number of 
>> others this seems to effect at various times.
>> 
>> So, my question is what happened?  My hypothesis is that changing the 
>> password outside of the web2py admin is a no no.  :-(  I haven't figure out 
>> how to configure webfaction to allow me admin access.
>> 
>> After dropping a couple of the tables that don't have important data in 
>> them, I noticed that the prefix on the .table file in the databases 
>> directory was different from all the others.  So, did changing the password 
>> cause the UUID to change?  If so, can I recover, and put migrate back to 
>> True by renaming all my .table files using the newer prefix?
>> Is there a better way to get things synced up so I could potentially make a 
>> schema change?
>> 
>> Thanks,
>> 
>> Brad
> 
> 
> 
> On Saturday, June 9, 2012 10:23:22 AM UTC-5, Jonathan Lundell wrote:
> On Jun 9, 2012, at 7:48 AM, Brad Miller wrote:
>> webfaction has a control panel, and I used their control panel to change the 
>> password.  It was the same mechanism I used to set up the database in the 
>> first place.  The only difference, of course, is that when I first set it up 
>> there were not any tables.  I don't know what they do behind the scenes when 
>> updating a password.
>> 
>> To me the most important question is how do I recover.  Right now I'm in a 
>> very undesirable state, where I have to have migrate=False in order for my 
>> application to work.  Any suggestions??
> 
> Massimo, Brad is talking about the database password, not the web2py admin 
> password.
> 
> Brad, the migration file prefix is a hash of the database connection string 
> (URL), which in your case includes the password. Your idea of renaming the 
> migration files sounds promising.
> 
> To avoid this in the future, assign your own prefix to the migration files by 
> using migrate='somestring' instead of migrate=True. Of course, doing so in 
> midstream will cause yet another renaming, so in advance you could copy all 
> your migration files to the new name and then restart, and finally remove the 
> old ones.
> 
> I think. 
> 
> 
>> 
>> Thanks
>> 
>> Brad
>> 
>> On Saturday, June 9, 2012 9:44:58 AM UTC-5, Massimo Di Pierro wrote:
>> You can change password outside of admin but need to hash it first. How did 
>> you change it?
>> 
>> 
>> 
>> On Saturday, 9 June 2012 09:22:02 UTC-5, Brad Miller wrote:
>> Hi,
>> 
>> Here's what happened.  I'm hosting a web2py application on webfaction 
>> (http://interactivepython.org)
>> 
>> This morning, after some maintenance I had tested everything and all was 
>> good.  Pages were working login/logout was working, database access was 
>> working perfectly.  Then, because I realized I had stupidly stored my 
>> password to the database (Postgresql) out on github, I went to the 
>> webfaction dashboard and changed the password for my database.  I dutifully 
>> made the same change in my configuration file and restarted.  Thats when 
>> everything came crashing down around me.
>> 
>> I was getting the dreaded table already exists error on every request.  
>> Changing migrate to false seemed to alleviate the problem, except for two 
>> tables where I had not explicitly set migrate to the value in my settings.
>> 
>> A little searching through this group is overwhelming in the number of 
>> others this seems to effect at various times.
>> 
>> So, my question is what happened?  My hypothesis is that changing the 
>> password outside of the web2py admin is a no no.  :-(  I haven't figure out 
>> how to configure webfaction to allow me admin access.
>> 
>> After dropping a couple of the tables that don't have important data in 
>> them, I noticed that the prefix on the .table file in the databases 
>> directory was different from all the others.  So, did changing the password 
>> cause the UUID to change?  If so, can I recover, and put migrate back to 
>> True by renaming all my .table files using the newer prefix?
>> Is there a better way to get things synced up so I could potentially make a 
>> schema change?
>> 
>> Thanks,
>> 
>> Brad
> 
> 
> 
> On Saturday, June 9, 2012 10:23:22 AM UTC-5, Jonathan Lundell wrote:
> On Jun 9, 2012, at 7:48 AM, Brad Miller wrote:
>> webfaction has a control panel, and I used their control panel to change the 
>> password.  It was the same mechanism I used to set up the database in the 
>> first place.  The only difference, of course, is that when I first set it up 
>> there were not any tables.  I don't know what they do behind the scenes when 
>> updating a password.
>> 
>> To me the most important question is how do I recover.  Right now I'm in a 
>> very undesirable state, where I have to have migrate=False in order for my 
>> application to work.  Any suggestions??
> 
> Massimo, Brad is talking about the database password, not the web2py admin 
> password.
> 
> Brad, the migration file prefix is a hash of the database connection string 
> (URL), which in your case includes the password. Your idea of renaming the 
> migration files sounds promising.
> 
> To avoid this in the future, assign your own prefix to the migration files by 
> using migrate='somestring' instead of migrate=True. Of course, doing so in 
> midstream will cause yet another renaming, so in advance you could copy all 
> your migration files to the new name and then restart, and finally remove the 
> old ones.
> 
> I think. 
> 
> 
>> 
>> Thanks
>> 
>> Brad
>> 
>> On Saturday, June 9, 2012 9:44:58 AM UTC-5, Massimo Di Pierro wrote:
>> You can change password outside of admin but need to hash it first. How did 
>> you change it?
>> 
>> 
>> 
>> On Saturday, 9 June 2012 09:22:02 UTC-5, Brad Miller wrote:
>> Hi,
>> 
>> Here's what happened.  I'm hosting a web2py application on webfaction 
>> (http://interactivepython.org)
>> 
>> This morning, after some maintenance I had tested everything and all was 
>> good.  Pages were working login/logout was working, database access was 
>> working perfectly.  Then, because I realized I had stupidly stored my 
>> password to the database (Postgresql) out on github, I went to the 
>> webfaction dashboard and changed the password for my database.  I dutifully 
>> made the same change in my configuration file and restarted.  Thats when 
>> everything came crashing down around me.
>> 
>> I was getting the dreaded table already exists error on every request.  
>> Changing migrate to false seemed to alleviate the problem, except for two 
>> tables where I had not explicitly set migrate to the value in my settings.
>> 
>> A little searching through this group is overwhelming in the number of 
>> others this seems to effect at various times.
>> 
>> So, my question is what happened?  My hypothesis is that changing the 
>> password outside of the web2py admin is a no no.  :-(  I haven't figure out 
>> how to configure webfaction to allow me admin access.
>> 
>> After dropping a couple of the tables that don't have important data in 
>> them, I noticed that the prefix on the .table file in the databases 
>> directory was different from all the others.  So, did changing the password 
>> cause the UUID to change?  If so, can I recover, and put migrate back to 
>> True by renaming all my .table files using the newer prefix?
>> Is there a better way to get things synced up so I could potentially make a 
>> schema change?
>> 
>> Thanks,
>> 
>> Brad
> 
> 


Reply via email to