test --keepdb and explicitly migrating the test database

[Shai Berger]

Hi,

While developing against a large project with many migrations, I found 1.8's
--keepdb option to the test command a life-saver, changing the time to run the
projects test from 7-8 minutes to under one (not even counting the tests
themselves). But it is still missing something.

If I develop a branch which includes migrations, and -- these things happen --
I need to change the migrations (whether because they had a bug, or because I
rebased the branch and I need to resolve conflicts), I'm basically out of luck
with --keepdb; there's no easy way to roll back migrations on the test
database (the only way would be to use a special settings file which defines the
test database as a "production" one to roll the migrations back).

I would like to have a "--test-db" option to the "migrate" command, which lets
me run migrations explicitly against the test database, assuming it exists
because of prior invocations of "test --keepdb" (and erroring out if it
doesn't, of course).

Is it just me?

Thanks,
Shai.

[Tim Graham]

I've made similar mistakes (corrupting the test database) while working on djangoproject.com. For that project, test database creation is quick enough that I just drop "--keepdb" and start fresh. I think this will usually be the simplest option for most users, but I don't see a reason not to support your proposal.

Rather than a separate command option, I wonder if a syntax something like --database=default[test] might be interesting? Running any management command that already takes the --database option against a test database seems useful.

[charettes]

FWIW I've been working around this limitation by adding a suffix
to my `DATABASES['alias']['TEST']['NAME']` setting if the project
VCS branch is not the default one.

e.g. for Git

import subprocess

branch = subprocess.check_output(['git', 'rev-parse', '--abbrev-ref', 'HEAD']).strip()

if branch != 'master':
    for alias in DATABASES:
        database = DATABASES[alias]
        name = database['NAME']
        test_name = database.setdefault('TEST', {}).setdefault('NAME', "test_%s" % name)
        database['TEST']['NAME'] = "%s_%s" % (test_name, branch)

Simon

[Marc Tamlyn]

Simon - that's great but still means ending up having to create a new test DB every time you switch to a new branch, something you do a lot if you're part of the QA process!

+100 to this feature, it would be super useful for me, especially when working with long running feature branches with migrations.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7ae240a4-3e21-43bd-a88f-dd75ba59810d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Shai Berger]

Hi again,

On Monday 25 January 2016 18:33:15 charettes wrote:
> FWIW I've been working around this limitation by adding a suffix
> to my `DATABASES['alias']['TEST']['NAME']` setting if the project
> VCS branch is not the default one.
>

What Marc said. That's nice, but doesn't solve my problem.

On Monday 25 January 2016 15:02:08 Tim Graham wrote:
> Rather than a separate command option, I wonder if a syntax something like
> --database=default[test] might be interesting? Running any management
> command that already takes the --database option against a test database
> seems useful.
>

Yes, I agree that would be better.

Shai.