Well, if it don't get problems with new tables/fields (migrating), its is
the solution I was looking for.
I just sugest separate the db connections config out of db.py in models,
creating a file 0db_config.py (or similar), to be preserved.
Usually, the settings of database connection(s) are diferent between local
an production environments, and haven't to be overwritten.
--
Atenciosamente
--
=========================
Alexandre Andrade
Hipercenter.com
2010/5/26 mdipierro <mdipie...@cs.depaul.edu>
> How about a flag when replacing an app via admin that preserves the
> content of databases/ sessions/ errors/ uploads/ cache/ ?
>
>
> On May 26, 1:08 pm, greenpoise <danel.sega...@gmail.com> wrote:
> > Hmmm..I see. Tough stuff. I wonder if there is room for improvement in
> > that area for web2py. Something that is transparent between the
> > developer and the production site.
> >
> > Thanks
> >
> > Dan
> >
> > On May 26, 1:28 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com>
> > wrote:
> >
> > > On May 26, 11:53 am, greenpoise <danel.sega...@gmail.com> wrote:
> >
> > > > Oh no, I am not developing where the live data resides. But when I
> > > > make changes to my application on my development environment, how do
> I
> > > > transfer/update those changes on my production site?
> >
> > > You have to work out a procedure that works with your production
> > > environment.
> >
> > > Typically, you will want a way to easily "undo" is anything goes
> > > wrong: I use hg on my production site (and include things like the
> > > databases files - i.e. table migrations - in that versioning).
> >
> > > Then, you will want to work out a cut-over procedure: if you make
> > > changes to modules, you will typically need to restart the web2py
> > > server; otherwise, you can push changes to a running site (!). You
> > > will probably want a staging area somewhere - either locally, or on
> > > your production site - where you will have some way to ensure the
> > > correct connection strings, etc. for your production site, before
> > > pushing out to it.
> >
> > > You could run your changes on your production server in a "beta"
> > > server (to make sure the environment doesn't affect anything, and that
> > > you have removed all your debug info, and that the correct connection
> > > string changes are in effect - I like to have mine automatically
> > > change on environment).
> >
> > > Then you need some way to move the files over to the production
> > > server, and finally the production instance. I use rsync, but you
> > > could use a graphical system, something life filezilla.
> >
> > > Basically, you have to work out your deployment procedure, and
> > > recovery paths.
> >
> > > Regards,
> > > - Yarko
> >
> > > > On May 26, 12:36 pm, Thadeus Burgess <thade...@thadeusb.com> wrote:
> >
> > > > > You probably don't want to develop on your live data.
> >
> > > > > To be able to migrate data the DAL includes two functions..
> >
> > > > > db.export_to_csv_file(open('/path.csv', 'w'))
> > > > > db.import_from_csv_file(open('/path.csv', 'r'))
> >
> > > > > So you can export your data, and then stick it on the server and
> > > > > re-import it. This also has the advantage that you can use
> something
> > > > > like PostgreSQL on your production machine.
> >
> > > > > --
> > > > > Thadeus
> >
> > > > > On Wed, May 26, 2010 at 9:39 AM, greenpoise <
> danel.sega...@gmail.com> wrote:
> > > > > > I have web2py production and my development environment. How
> would I
> > > > > > go for leaving the data intact in my production? Is there a way?
> What
> > > > > > I did is I packedAll the project and took it to my production but
> I
> > > > > > will keep working on it on my development environment. Is this
> how it
> > > > > > should be done?
> >
> > > > > > Thanks
>
