as I thought about what I'd written, I want to be sure to not mislead you
with my web2py entusiasm:
- I think we did NOT actually migrate db tables after we went live...
- with two exceptions:
- I (much to Massimo's concern) extended a table, added a boolean
column (and had not problems;
- I added a table (which, during development with the Financial Aid
manager - before anyone else used it - I effected DAL migrations a few
times)
So that you are not mislead, it's not a good idea in a production
environment in general (see my caveats above about testing on real server
environment, and making planned cut-overs).
It does work, and I would not recommend it for 2 reasons: it's not safe (if
something goes wrong, you risk live data) - always design your migrate/merge
process with fall back / recovery in mind (e.g. parallel test system which -
when successful, you can cut-over to); it has not seen enough production
use, and different backends will behave differently.
Hope that puts a little more reality on it.
Regards,
Yarko
On Sun, Mar 1, 2009 at 1:13 PM, Yarko Tymciurak <[email protected]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
