mirror of
https://github.com/django/django.git
synced 2025-08-03 10:34:04 +00:00
Removed support for custom SQL per deprecation timeline.
This commit is contained in:
parent
a420f83e7d
commit
4aa089a9a9
26 changed files with 10 additions and 368 deletions
|
@ -140,9 +140,7 @@ database to make sure they work as expected::
|
|||
Apply all migrations: books
|
||||
Synchronizing apps without migrations:
|
||||
Creating tables...
|
||||
Installing custom SQL...
|
||||
Installing indexes...
|
||||
Installed 0 object(s) from 0 fixture(s)
|
||||
Running migrations:
|
||||
Applying books.0003_auto... OK
|
||||
|
||||
|
|
|
@ -984,15 +984,6 @@ The most straightforward way of creating a fixture is to use the
|
|||
already have some data in your database. See the :djadmin:`dumpdata
|
||||
documentation<dumpdata>` for more details.
|
||||
|
||||
.. admonition:: Initial SQL data and testing
|
||||
|
||||
Django provides a second way to insert initial data into models --
|
||||
the :ref:`custom SQL hook <initial-sql>`. However, this technique
|
||||
*cannot* be used to provide initial data for testing purposes.
|
||||
Django's test framework flushes the contents of the test database
|
||||
after each test; as a result, any data added using the custom SQL
|
||||
hook will be lost.
|
||||
|
||||
Once you've created a fixture and placed it in a ``fixtures`` directory in one
|
||||
of your :setting:`INSTALLED_APPS`, you can use it in your unit tests by
|
||||
specifying a ``fixtures`` class attribute on your :class:`django.test.TestCase`
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue