[Django] #22834: The builtin migrations being the only way to do migrations breaks data migrations/fixtures in tests

11 views
Skip to first unread message

Django

unread,
Jun 14, 2014, 4:56:39 AM6/14/14
to django-...@googlegroups.com
#22834: The builtin migrations being the only way to do migrations breaks data
migrations/fixtures in tests
-------------------------------+------------------------
Reporter: gc@… | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 1.7-beta-2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------
The docs say:


When you run ./manage.py test, Django looks at the TEST_RUNNER setting to
determine what to do. By default, TEST_RUNNER points to
'django.test.runner.DiscoverRunner'. This class defines the default Django
testing behavior. This behavior involves:

Performing global pre-test setup.
Looking for tests in any file below the current directory whose name
matches the pattern test*.py.
Creating the test databases.
'''Running migrate to install models and initial data into the test
databases.'''
Running the tests that were found.
Destroying the test databases.
Performing global post-test teardown.

This is not true. There is no way to have initial data in the database for
testing. The process of creating the test database also flushes it.
Previously, a common pattern was to have initial data in south migrations
and this worked, since south came later. Now, it is impossible to have
initial data for tests, without test fixtures.

This is not documented in initial data, it says you can't use custom SQL
for tests, but then it says you should use fixtures for tests, even though
fixtures are deprecated for production use, which is... well, weird.
Additionally, you cannot use data migrations, since those will be flushed
as well.

Finally, looking at the code:
https://github.com/django/django/blob/stable/1.7.x/django/db/backends/creation.py#L376

I don't understand how this could work, since people that have
transactions are now screwed, vs no transaction.

--
Ticket URL: <https://code.djangoproject.com/ticket/22834>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Jun 16, 2014, 8:28:47 AM6/16/14
to django-...@googlegroups.com
#22834: The builtin migrations being the only way to do migrations breaks data
migrations/fixtures in tests
-------------------------------+--------------------------------------

Reporter: gc@… | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 1.7-beta-2
Severity: Normal | Resolution:
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 timo):

* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0


Comment:

I think this is a duplicate of #22487 which was resolved just a couple
days before your report so perhaps you didn't see it. Could you confirm?

That said, I believe we still need to update the documentation as you
noted.

--
Ticket URL: <https://code.djangoproject.com/ticket/22834#comment:1>

Django

unread,
Jun 16, 2014, 10:02:14 AM6/16/14
to django-...@googlegroups.com
#22834: The builtin migrations being the only way to do migrations breaks data
migrations/fixtures in tests
-------------------------------+--------------------------------------

Reporter: gc@… | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 1.7-beta-2
Severity: Normal | Resolution:
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 anonymous):

I think that's a terrible solution, though. :-( The simple solution would
be to have an argument for tests, that makes it not flush. We worked
around by defining our own flush that does nothing, but that's an ugly
hack.

Additionally, the solution is not only slow and ugly, but broken since it
makes you force no transactions (no idea what the other implications of
this are)

--
Ticket URL: <https://code.djangoproject.com/ticket/22834#comment:2>

Django

unread,
Jun 16, 2014, 4:29:30 PM6/16/14
to django-...@googlegroups.com
#22834: The builtin migrations being the only way to do migrations breaks data
migrations/fixtures in tests
-------------------------------+--------------------------------------
Reporter: gc@… | Owner: nobody
Type: Uncategorized | Status: closed
Component: Migrations | Version: 1.7-beta-2
Severity: Normal | Resolution: duplicate
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 aaugustin):

* status: new => closed
* resolution: => duplicate


Comment:

Thanks for the kind words. I gather from your comment that the issue you
reported is fixed, even though you disagree with the fix.

I'm not sure what the issue with transactions is. Since it's a different
one, it belongs to a separate ticket. I'll need a bit more information to
understand it.

Finally, if you can provide a better and simpler solution that still meets
all the constraints discussed in #22487, including the mailing-list thread
linked to in the first comment, please open a new ticket and submit a
patch or a pull request! Thank you.

--
Ticket URL: <https://code.djangoproject.com/ticket/22834#comment:3>

Reply all
Reply to author
Forward
0 new messages