On Wednesday 15 January 2014 00:02:52 Michael Manfre wrote:
> On Tue, Jan 14, 2014 at 3:26 PM, Shai Berger <s...@platonix.com> wrote:
> >
> > Your suggestion, if I understand it correctly, gives the user two options:
> >
> > 1) Use separate credentials, and perhaps even a separate service, for
> > testing;
> > this implies that the test database stays alive all the time.
>
> As it stands, the privileges for running the tests are greater than those
> needed to run syncdb (or runserver), so I'm not sure what point you are
> trying to make.
I did not understand your proposal correctly; I had thought you intended to
put the credentials for accessing the test database on equal footing with the
credentials for accessing the main database.
> This assumes you're not using Oracle and need to provide the
> slew of other configuration values, which should really be moved to
> OPTIONS.
>
I am still undecided about this one. We have backend-agnostic test-only
parameters (MIRROR and DEPENDENCIES, at least), we have backend-specific
parameters which apply to both testing and "production" (which usually go into
OPTIONS). I want the test-only parameters tucked away, and I'm not sure in
which of the above the test-only backend-specific parameters should go; but my
tendency is toward 'TEST'.
> > 2) Write configurations with repetitions or some other awkwardness, e.g.
> >
> > [example redacted]
> >
>
> This is not what I envisioned. By separate aliases, I don't mean to just
> add more test aliases in with your existing settings. What I mean is that
> each database alias defined in a settings file should define a single
> connection configuration, not potentially two different configurations. If
> you need a different configuration for testing, put them in a separate
> configuration file.
>
> Example:
>
> # settings.py - for local development
> DATABASES = {
> 'default': {
> ...
> # 'CAN_USE_FOR_TESTS': False, # Protect database from unit test trampling
> }
> }
>
>
> # test_settings.py - for unit tests
> DATABASES = {
> 'default': {
> 'ENGINE': 'oracle',
> 'NAME': 'test_my_db', # This was TEST_NAME
> 'USER': 'dba_user', # This is a user with credentials to drop a database
> ...
> 'OPTIONS': {
> # backend specific settings belong here
> 'TEST_CREATE': True,
> 'TEST_TBLSPACE': 'test_',
> 'CHARSET': 'utf-8', # Or leave named as TEST_CHARSET
> ...
> },
> 'CAN_USE_FOR_TESTS': True, # DB is safe to trample with tests
> }
> }
>
So, If I understand correctly (this time), your "test settings" are a strict
superset of your "local development" settings.
But I don't like the separation at all. It makes sense for some enterprise
environment, but not for a setting where each developer has their own database
installation. Making it in any concrete way will require the project to make
some decisions about the structure of the settings files, which we have avoided
for a very long time -- it is certainly out of scope of a little settings
clean-up. And some projects will just want to do something like 12factor,
where all credentials come from the environment rather than settings files, and
this is how you get different enterprisey settings.
If your suggestion is to make the separate files concretely supported by Django
-- e.g. use a different settings file, by default, for the test commands --
please flesh it out. I suspect I still don't quite follow where you're going
with this.
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/201401200012.02517.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.
