[Django] #33177: Setting DATABASES[alias]["TEST"]["MIGRATE"] = False should mean that `migrate` isn't run.
Django
`migrate` isn't run.
---------------------------------------------+------------------------
Reporter: limedaniel | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: dev
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
---------------------------------------------+------------------------
We've been working on a project which uses Django heavily on the `default`
database but also communicates with a number of other databases for other
unmanaged data. For testing purposes, we have a custom test runner that
dumps the external db schema into a local db and we then leverage Django's
`TestCase` class and treat them like any other database: the expectation
being that data inserted in a test will be rolled back at the end of the
test. For the most part, this works reasonably well, though it's quite
slow to start.
In digging into how I might improve the start-up speed, I realised that
despite `MIGRATE` being set to `False` for all of these external
databases,
[https://github.com/django/django/blob/28f66b2783e52d5be51887c31cd2be907b820e11/django/db/backends/base/creation.py
Django is still running `migrate` against these databases]. This means
that when the test run starts, Django writes our entire database schema to
the `default` database ''and'' the three other external databases (albeit
as a syncdb rather than running all migrations), only to be destroyed and
overwritten with our own schemas.
It seems to me that if there's a flag called `MIGRATE` that you can set to
`False`, that that would mean "don't run `migrate` for this database". If
there's a compelling reason to still run `migrate` against all databases
listed, it would be good then at least to mention in the docs that this is
what's actually happening. Better still would be some pointers around how
to work with an unmanaged database in tests.
--
Ticket URL: <https://code.djangoproject.com/ticket/33177>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
`migrate` isn't run.
Reporter: Daniel Quinn | Owner: nobody
Type: New feature | Status: closed
Component: Testing framework | Version: dev
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* status: new => closed
* type: Bug => New feature
* resolution: => wontfix
Comment:
Thanks for the report.
> It seems to me that if there's a flag called `MIGRATE` that you can set
to `False`, that that would mean "don't run `migrate` for this database".
It's strictly documented how `MIGRATE` works: ''"When set to False,
**migrations** won’t run when creating the test database. This is similar
to setting `None` as a value in `MIGRATION_MODULES`, but for all apps."'',
more details can be found in `MIGRATION_MODULES` docs.
''"**migrations won’t** run when creating the test database"'' it's not
the same as ''"**`migrate` command won't** run"''.
> If there's a compelling reason to still run `migrate` against all
databases listed, it would be good then at least to mention in the docs
that this is what's actually happening.
Yes it's see #32012 and 77caeaea888d1744416b213036ff29699758de76.
I don't think that your use case with a custom workflow and a custom
`TestCase` is (or should be) supported by the `MIGRATE` setting. You can
try to create a custom `migrate` command and skip apps without a migration
module.
--
Ticket URL: <https://code.djangoproject.com/ticket/33177#comment:1>
Django
`migrate` isn't run.
Reporter: Daniel Quinn | Owner: nobody
Type: New feature | Status: closed
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Daniel Quinn):
I'm not sure I understand the reasoning above, but if the project
considers this a wontfix, I'll find a way to roll with it.
Can I ask then, is there an officially sanctioned way to write a Django
project that talks to external, unmanaged databases that will also allow
you to write tests against local copies of those databases for integration
tests? I had thought that setting `MIGRATE=False` was it, but as it is,
simply having these databases in `settings.DATABASES` makes the test
runner write to them, which is really not awesome.
--
Ticket URL: <https://code.djangoproject.com/ticket/33177#comment:2>