Annet - We do migrations on live PyCon - and I do NOT recommend it; as Massimo points out the process you follow, and your awareness of what that means to a live site is crucial (we have so far only had one "problem" because of our bold and foolish process).
In general, I use rsync to take a snapshot of the live site models (both Massimo and I make changes, so important to keep these in sync) into a bzr repository. Massimo makes an entire archive; I try only the source and sql-logs etc. (I didn't do the latter once, and it was scary!). Then we make changes - as Massimo says - in a local environment; not _all_ things are connected in a local environment (eg visa charges), so some care in setting up development versus deployment in the code-base is necessary. Once the local works, it then is rsync'd (less the devel switch) up to the bzr repository, and at an agreed on time (usually late, late at night when minimal activity on the server) a "all at once" rsync to the server and a quick check take care of it. The really better idea is to have a development version of what you propose on your server, and make changes to that url; test; and then make a scheduled changover. The point is all this requires care and planning. The migrations are possible, and we have done them to a "live" system, and really never should have but managed to not get hurt by doing so. web2py is very capable of the migrations, even if you're foolish enough to do them on a live system - but don't! Plan your processes, watch the limitations of the underlying systems and test them; plan your cut-over process. web2py helps _a lot_ --- but if you expect _too_ much from it, you can get sloppy... and then you will be sorry. Hope this view "behind the curtain" is helpful. Yarko On Sun, Mar 1, 2009 at 9:44 AM, mdipierro <[email protected]> wrote: > > All I am saying is that if you need to do a migration, first take > web2py down, then run it on localhost only, they do the migration and > debug eventual errors. Do not change your model while your app is > being exposed to users. > > There is nothing wrong in principle but there is always the > possibility of a typo or other minor error and you do not want to give > lots of tickets to your users. > > Said this. I always change my models in production. We did it twice > with the PyCon registration site. > > Massimo > > On Mar 1, 9:39 am, annet <[email protected]> wrote: > > Alexandre and Massimo, > > > > Thanks for your replies. > > > > > Anyway, for various reason I would not suggest doing migrations while > > > in production because they may lock the database for some time. > > > > I am reading a bachelor in computer science so I am not a complete > > novice when it comes to analysis and design, however, no matter how > > well I designed my model, one day I will have to do migrations because > > of changes in the domain (relevant world). How do I proceed in that > > case? > > > > What about the idea to put the database model in the init application > > and copy and paste it to the applications that make > > use of the model and set migrate to False? > > > > Best regards, > > > > Annet > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
