Hi,

On Tuesday 14 January 2014 21:35:04 Michael Manfre wrote:

> Why are we not encouraging people to define different aliases for testing?
> Many of those TEST_ settings could be given meaning to the database
> configuration without being specific to running tests. Several of those
> TEST_ settings would no longer be necessary and several more would be
> properly rooted under OPTIONS because they are specific to a database's
> connection.
> 

The way testing currently works is by creating a throw-away database, running 
the tests on that, and throwing it away. This means, among other things, that 
you need settings for a database service and credentials for a user that can 
create databases on this service. The common use-case is that this user is 
your "main" database user, and the service is your main service. 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.
2) Write configurations with repetitions or some other awkwardness, e.g.

default_db = {
        'ENGINE': 'this',
        'HOST': 'that',
        'NAME': 'the_other',
        'USER': 'me',
        'PASSWORD': 'my secret',
}

DATABASES = {
        'default' : default_db,
        'test_default' : dict(default_db,
                NAME='test_the_other',
                IS_TEST=True),
}

I don't see that as an improvement; you seem to be optimizing for the edge 
case at the expense of the common case.

In particular, the explosion of TEST_* settings for Oracle all have to do with 
the creation of a new user and tablespace; in the scenario where the user is 
created for the test and deleted at its end, your suggestion doesn't seem to 
make much sense -- normal connections don't deal with it, and the test 
connection needs a "dba" connection to start from.

If I have misunderstood your suggestion, please clarify.

Thanks,
        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/201401142226.50182.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to