Re: test --keepdb and explicitly migrating the test database
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.
Re: test --keepdb and explicitly migrating the test database
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.
On 25 January 2016 at 16:33, 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.
>
> 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
>
>
> Le lundi 25 janvier 2016 07:16:52 UTC-5, Shai Berger a écrit :
>>
>> 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.
>>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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.
>
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CAMwjO1HKiMrhqi%3DQWCd_9GoYHKn3Bp52SQnTTW0OafK1msMzyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: test --keepdb and explicitly migrating the test database
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
Le lundi 25 janvier 2016 07:16:52 UTC-5, Shai Berger a écrit :
>
> 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.
>
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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.
Re: test --keepdb and explicitly migrating the test database
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. On Monday, January 25, 2016 at 7:16:52 AM UTC-5, Shai Berger wrote: > > 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. > -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/1518cb58-4ab7-4c28-a158-4b46d3599bda%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
test --keepdb and explicitly migrating the test database
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.
