Hi,

Here is the the way that we have done it for the last 18 months, and has
proven very useful and almost human error free.

I've posted all the concept inside:
http://djangosnippets.org/snippets/2349/

This method allows you to separate the settings.py based on the local server
hostname, and/or the environment variable specified.

For example:

DJANGO_ENVIRONMENT=dev /path/to/manage.py shellDJANGO_ENVIRONMENT=prod
/path/to/manage.py runfcgi




On Sun, Feb 6, 2011 at 6:37 AM, Mike Ramirez <gufym...@gmail.com> wrote:

>  On Saturday, February 05, 2011 01:52:43 am Amit wrote:
>
> > Hello,
>
> > First of all one should go through with below link;
>
> >
>
> >
> http://stackoverflow.com/questions/4887851/django-database-settings-for-pro
>
> > duction-server
>
> >
>
> >
>
> > Now, let come up with my hurdle. I am using a database lay out in
>
> > filesystem(windows) say;
>
> > C:/miami/data.db
>
> >
>
> > I have to use same database with production server, since I don’t have
>
> > avail corresponding database in PostGreSQL.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Amit.
>
> Witht his situation you might want to have a local_settings.py file. This
> file should be local to the django instance and not part of any revision or
> deployment strategy unless you're providing a templated form for others to
> modify (name the templated local_settings.py something else like
> local_settings.tmpl).
>
> In settings.py add this to the top:
>
> from local_settings import *
>
> Remove the database settings from settings.py (and anything else you've
> added to local_settings.py)
>
> in your local_settings.py you have your database settings and any other
> (path based and/or installed apps) settings that are specific to the server.
>
> I've found this approach optimal when dealing with databases, templates,
> middleware, context processors, and installed apps. I can keep my debugging
> stuff out of the production version.
>
> Google "local_settings.py" for more examples. Personally I don't use the
> try/except form shown on some of the blogs, that's because I want it to fail
> loudly and clearly when I attempt to use it with a missing/broken
> local_settings.py.
>
> As a friend once told me, if you're going to fail, fail spetacularly. I
> find this very true with programming.
>
> Mike
>
> --
>
> Detroit is Cleveland without the glitter.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Reply via email to