Voltron I didn't think you came on strong at all, it's just there's a lot I don't know about :-)
This is the best (responsive/friendly/useful) forum I have come across - but then I don't get out much :-) On Oct 26, 4:14 pm, voltron <[EMAIL PROTECTED]> wrote: > Hey Bilf, sorry if my suggestioin came on , erm , "strong" that was > not my intention. I really appreciate you taking the time to help me > solve this problem. I just wanted to make emphasis on that particular > point because I have mentioned problems with migration once, maybe > twice before on the forum. > > I will,as soon as possible try to test on your workaround. I would > then not have any headaches when the PMs come over with their > modifications :-) > > Thanks! > > On 26 Okt., 15:45, billf <[EMAIL PROTECTED]> wrote: > > > Voltron > > > I am not agreeing/disagreeing re migrate switch - you may well be > > right - I don't know. > > > Re your procedure: my tests proved to me that running "upload > > application" when the application already exists DOES NOTHING. The > > models, controllers, etc are unchanged. Therefore to change the > > application on your LIVE server you must do one of two things: > > > 1) Delete the application then "upload application": if you do this > > you will get "table exists" errors. > > > 2) Do not delete the application and extract the tar manually as > > described in my previous post; if you do this it will all work as you > > want. > > > At least try it (on a test server) and confirm I am right or not. If > > it works ok then at least you have a working solution and can address > > the migrate switch question at your leisure :-) > > > On Oct 26, 2:00 pm, voltron <[EMAIL PROTECTED]> wrote: > > > > I still insist, unless convinced otherwise, that the migrate switch > > > at the moment logically wrong if it takes a string for the table > > > files, there should be a separate variable that controls the creation > > > of .table files because one would not want to migrate a > > > database( migrate = False) but just modify an existing database based > > > on a modified model > > > Specifics: > > > > 1. I use PostgreSQQL > > > 2. The initial upload was done by packing the BETA/ local version of > > > the appliance to the LIVE server > > > > After changes, only the BETA server appliance gets deleted and the new > > > version from my local machine gets uploaded to it using upload app. I > > > cannot use this procedure for the LIVE server due to the problems > > > above so i just overwrote the model file of the LIVE server appliance > > > expecting the web2py to ALTER the tables, but this does not happen > > > because .table files exist. > > > > All 3 appliances are identical, if I make changes to the model file in > > > local version of the appliance, the changes are made, so I should > > > expect that just uploading the modified model file to the appliance on > > > the LIVE server should ALTER the tables as it did on my local machine. > > > Nothing else has changed except the a few lines in the model file. > > > > I still insist, unless convinced otherwise, that the migrate switch > > > at the moment logically wrong if it takes a string for the table > > > files, there should be a separate variable that controls the creation > > > of .table files because one would not want to migrate a > > > database( migrate = False) but just modify an existing database based > > > on a modified model --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
