On 9/4/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
I briefly considered this approach when the TEST_DATABASE_NAME suggestion came up. However, I was concered about the possibility for accidentally nuking your production database. If you ever forget to pass your test settings file to ./manage.py test, your production database will be deleted and rewritten.
However, now that TEST_DATABASE_NAME is in place (providing protection for the production database), this approach seems like a reasonable solution to Ned's problem (i.e., setting up some overrides to allow rapid testing turnaround). It also means that you can optimize any other setting you want without introducing an explosion of command line arguments to manage.py.
Thanks for the suggestion.
Yours,
Russ Magee %-)
and use ./manage.py --settings=myapp.testsettings.
I briefly considered this approach when the TEST_DATABASE_NAME suggestion came up. However, I was concered about the possibility for accidentally nuking your production database. If you ever forget to pass your test settings file to ./manage.py test, your production database will be deleted and rewritten.
However, now that TEST_DATABASE_NAME is in place (providing protection for the production database), this approach seems like a reasonable solution to Ned's problem (i.e., setting up some overrides to allow rapid testing turnaround). It also means that you can optimize any other setting you want without introducing an explosion of command line arguments to manage.py.
Thanks for the suggestion.
Yours,
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
