Ah ok, related topic with a different twist... I get there is no easy way or dictated way of achieving this... I guess depending of the the changes you made you will have to figure out what change to the backend you may have made that you will have to regress gracefully in order to make sure that your old app can work and that you preserve the proper that, this may also include sessions files which may or may not be inside database depends on how you deploy your app...
Sessions are particuarly important if you save some state variables there that may be related to your cart content... Hope for you that the schema doesn't change too much for example you only add new tables, that way you don't even have to bother with schema change you just backup the sessions file of the actual deployed app to later restore them into the restored previous app, since you old app will be agnostic of the new table which doesn't prevent it to work properly as if the table wasn't there... So, in that scenario, you only have to take care of restoring properly the old app and put back the recent sessions files which should still work the same if you didn't update web2py... Richard On Mon, Jan 4, 2016 at 11:10 AM, Ron Chatterjee <achatterjee...@gmail.com> wrote: > Thanks for your inputs but may be I didn't explain the problem right. I am > not worried about auto migration. Here is a scenario, let's say I have 100 > users and they are using the site daily. I wrote a "def" function but that > breaks the current front end installation (in other words, just the python > code excluding DB. May be overwriting some variables. Whatever the reason > may be). What I will need to do now is reinstall the new resigned app from > my local repository to "python-anywhere" hosting, but I would like those > 100 users to have access the sites the way they were. In other words, If > they had something in the "curt" last night, it will still be there logging > in the next day. What would be the best practice to achieve that result. > That was my discussion. > > > On Monday, January 4, 2016 at 10:02:18 AM UTC-5, Richard wrote: >> >> Don't understand exactly what the core of your issue... >> >> You ask how to handle deliver new version for a staging/production system >> while making sure you don't messup the DB with web2py automigration feature? >> >> If so, one of the answer is backup/backup/backup... Before making any new >> deployement you backup your complete installation, and you dump the DB into >> a SQL script which create the entire DB and insert the dumped data... So if >> anything nasty happen you can restore everything... Then you disabled the >> app you want to upgrade with the admin interface if you keep it and secure >> access to it properly (mine is only accessible throught ssh tunnel from >> remote web2py instance which is different from the main web2py instance, it >> slow but is save you ass when you need to quick fix something... Then you >> proceed with you deployement (upgrade) app... Then you have to migrate >> false migrate_fake true and then migrate true to allow web2py to retrieve >> it proper mapping and effectivly migrate changes to db... Then you restart >> main web2py instance and cross your finger everything fines... >> >> Personnaly, I disabled completly web2py auto migration in production and >> I maintain an SQL script for any new version that contains any update to >> the DB schema... So as soon as I make a change to the app that requires db >> models change I manually code this change into SQL... It painfull, but I am >> sure that my production db is never update un properly by something I don't >> fully control... >> >> When I will take time to do it, what I want to do, is to implement an ETL >> routine that will allow to take advantage of web2py automigration while >> keeping data safe... It will surely turn with some overhead to maintain the >> ETL mapping... But it allow for more flexibility in data manipulation... >> And let me acheive the goal of having the backend schema fully under >> version control since I can let web2py recreate the entire DB at every >> upgrade and move back data into the new container... It will allows also >> more flexibility to improve backend schema since there is more convenient >> tool to manipulate data into ETL then plain SQL and data become a flux of >> data instead of been kind of binded to the backend schema because >> everything get always update and maniuplate together... >> >> Just some thought about how to organize... It may be unrelevant for >> bigger project, but for small team and solo project, I think it makes >> sens... >> >> Richard >> >> On Mon, Jan 4, 2016 at 7:01 AM, Ron Chatterjee <achatte...@gmail.com> >> wrote: >> >>> db is on the hosting platform. Question is related to what happens after >>> the deployment? >>> >>> >>> On Monday, January 4, 2016 at 4:36:30 AM UTC-5, Niphlod wrote: >>>> >>>> where is the db ? >>>> >>>> On Monday, January 4, 2016 at 7:17:07 AM UTC+1, Ron Chatterjee wrote: >>>>> >>>>> >>>>> Happy New Year Everyone, >>>>> >>>>> I want to understand what everyone think about this problem. Let's say >>>>> I have an app installed in python anywhere. I have few users. There are >>>>> some changes to my app or for various other reason I need to delete the >>>>> current code with an updated version of my web2py application but I would >>>>> like to keep the database intact with all the current users and their >>>>> activities to date. What are the best way to accomplish this? >>>>> >>>>> a) Keep a local copy of the app and the backend from python anywhere. >>>>> Make changes to the app and reinstall. >>>>> b) Load the database and extract the information to the updated app >>>>> and reinstall both >>>>> c) something else? >>>>> >>>>> Any thoughts? >>>>> >>>> -- >>> Resources: >>> - http://web2py.com >>> - http://web2py.com/book (Documentation) >>> - http://github.com/web2py/web2py (Source code) >>> - https://code.google.com/p/web2py/issues/list (Report Issues) >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "web2py-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to web2py+un...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to web2py+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
