Provide a way for tests to run on an existing empty DB

[Curtis Maloney]

Periodically users ask in IRC for help running tests when the user they connect as can not create a DB.

The reasons for this situation tend to be their DBA won't allow it, or their corporate policy doesn't permit it.

Regardless, Django fails because when not using keepdb, it attempts to create the db _always_, and only catches "duplicate DB name" errors to indicate it already exists.

However, Postgres checks for CREATE DB permissions _before_ checking if the DB exists, so Django sees it as a generic "DB creation problem" and bails.

If we, instead, used the existing function [used by the keepdb logic] to test if the DB exists, we could smooth the path for users in the above situation.

I've started a patch which is currently _very_ wrong, and is awaiting feedback as requested on the django-dev mailing list.

​https://github.com/django/django/pull/10349

[Tim Graham]

As I said on ​django-developers, I don't see why we couldn't recommend --keepdb for this use case?

[Curtis Maloney]

To clarify...

Basically, I want to separate create/drop of the DB with create/drop of the objects within the DB, where currently we conflate the concepts.

Currently we have "must create db" vs. "may reuse db"

So we allow "must create db" which implies "must start clean"
We can do "may reuse db", but that currently forces "may reuse objects".

I'm trying to enable "may reuse db" with "must start clean".

[Tim Graham]

Thanks for clarifying. Maybe the Oracle-specific ​CREATE_DB setting in DATABASES 'OPTIONS' does what you want to do for PostgreSQL? Possibly that might just be another way to do "keepdb" -- I didn't investigate enough to confirm.

[Curtis Maloney]

Replying to Tim Graham:

Thanks for clarifying. Maybe the Oracle-specific ​CREATE_DB setting in DATABASES 'OPTIONS' does what you want to do for PostgreSQL? Possibly that might just be another way to do "keepdb" -- I didn't investigate enough to confirm.

From the docs:

If it is set to False, the test tablespaces won’t be automatically created at the beginning of the tests or dropped at the end.

This is _close_ to what I was after. However, I'd want it to create and tear down the models, etc.

So really we want to build a matrix of steps:

1. (a) Create DB --OR-- (b) Clear DB
2. Apply migrations
3. Revert migrations
4. Drop DB

Normally we affect all steps, with 3 implied by 4. Using --keepdb skips 3 and 4. I'm looking for a way to allow only 1(b), 2, and 3.

My current solution to step 3 is excessive, in that it will drop _everything_, not just the objects we created in migrations. I don't believe there is currently a simple way to migrate everything to ZERO, instead we'd likely need to iterate the installed apps and do them individually.

[Saarthak Maini]

Thank you for reporting the ticket.

As the ticket has been inactive for about 5 years, it would be suitable to close the same.

[Mariusz Felisiak]

Saarthak, we don't close tickets just because they are old.