How can we specify the name of the test database?

[Vadorequest]

Django supports a custom name for the test database, how can we specify this somehow?

See https://docs.djangoproject.com/en/1.8/ref/settings/#test

[Brodan]

I'm also currently dealing with this issue. Any solutions?

[mattseymour]

Currently, the database string allows for specifying the current fields.

• Engine
• User
• Password
• Host
• Port
• Name (database name)

All of these are set through the basic usage of the database string (for example: mysql://USER:PASSWORD@HOST:PORT/NAME

One proposal could be to use querystring arguments for additional database options.

For top level database options not already included in the database string (time_zone, conn_max_age, autocommit, atomic_requests). They could look something like:

mysql://USER:PASSWORD@HOST:PORT/NAME?CONN_MAX_AGE=120&AUTOCOMMIT=True

For database options or test which are a dictionary within the databases settings we could use a key prefix to represent the dictionary it is part of. This could be something like TEST__ to represent TEST options.

An example could be:

mysql://USER:PASSWORD@HOST:PORT/NAME?TEST__NAME=mytestdb

This proposal should also be able to help support other DB options such as SSL which i set under the OPTIONS. An example of such usage could be:

mysql://USER:PASSWORD@HOST:PORT/NAME?OPTIONS__NAME=mytestdb&OPTIONS__SSL__key=/opt/_certs/client-key.pem&OPTIONS__SSL__cert=/opt/_certs/client-cert.pem

Let me know your thoughts.

[jacobian]

@mattseymour my gut reaction is that this looks pretty inelegant; I don't love cramming stuff into the URL like this, and I find turning the flat URL into a dictionary... just too much. I think there's a certain point where, if you're doing complex stuff, you should just dive into the settings file.

My feeling is: the point of this library is to take a DATABASE_URL that's been handed to you by a provider (Heroku, Azure, etc) and use it with a minimum of fuss. That URL isn't going to have Django-specific stuff, so why support it?

I like the direction that #116 is taking, moving some of this stuff into the config() call. It's a bit cleaner than

DATABASES = dj_database_url.config()
DATABASE["default"]["TEST"]["name"] = "whatever"

But still doesn't require being all this URL stuff. Does that approach seem ok to you?

[mattseymour]

Makes sense, I guess it depends on the use case of what people are willing to put into the database urls.
I was not sure if we wanted a purely url solution or if core information in the URL and additional
details in the configuration files.

In either case, I think it would be good to put in the read me the limitations and the thought process behind the scope of the library. Almost like what you put in your comment:

the point of this library is to take a DATABASE_URL that's been handed to you by a provider (Heroku, Azure, etc) and use it with a minimum of fuss. That URL isn't going to have Django-specific stuff.