Removed support for custom SQL per deprecation timeline.

This commit is contained in:
Tim Graham 2014-12-26 13:56:08 -05:00
parent a420f83e7d
commit 4aa089a9a9
26 changed files with 10 additions and 368 deletions

View file

@ -3,15 +3,7 @@ Providing initial data for models
=================================
It's sometimes useful to pre-populate your database with hard-coded data when
you're first setting up an app. There's a couple of ways you can have Django
automatically create this data: you can provide `initial data via fixtures`_, or
you can provide `initial data as SQL`_.
In general, using a fixture is a cleaner method since it's database-agnostic,
but initial SQL is also quite a bit more flexible.
.. _initial data as sql: `providing initial sql data`_
.. _initial data via fixtures: `providing initial data with fixtures`_
you're first setting up an app. You can provide initial data via fixtures.
.. _initial-data-via-fixtures:
@ -91,77 +83,3 @@ directories.
Fixtures are also used by the :ref:`testing framework
<topics-testing-fixtures>` to help set up a consistent test environment.
.. _initial-sql:
Providing initial SQL data
==========================
.. deprecated:: 1.7
If an application uses migrations, there is no loading of initial SQL data
(including backend-specific SQL data). Since migrations will be required
for applications in Django 1.9, this behavior is considered deprecated.
If you want to use initial SQL for an app, consider doing it in a
:ref:`data migration <data-migrations>`.
Django provides a hook for passing the database arbitrary SQL that's executed
just after the CREATE TABLE statements when you run :djadmin:`migrate`. You can
use this hook to populate default records, or you could also create SQL
functions, views, triggers, etc.
The hook is simple: Django just looks for a file called ``sql/<modelname>.sql``,
in your app directory, where ``<modelname>`` is the model's name in lowercase.
So, if you had a ``Person`` model in an app called ``myapp``, you could add
arbitrary SQL to the file ``sql/person.sql`` inside your ``myapp`` directory.
Here's an example of what the file might contain:
.. code-block:: sql
INSERT INTO myapp_person (first_name, last_name) VALUES ('John', 'Lennon');
INSERT INTO myapp_person (first_name, last_name) VALUES ('Paul', 'McCartney');
Each SQL file, if given, is expected to contain valid SQL statements
which will insert the desired data (e.g., properly-formatted
``INSERT`` statements separated by semicolons).
The SQL files are read by the :djadmin:`sqlcustom` and :djadmin:`sqlall`
commands in :doc:`manage.py </ref/django-admin>`. Refer to the :doc:`manage.py
documentation </ref/django-admin>` for more information.
Note that if you have multiple SQL data files, there's no guarantee of
the order in which they're executed. The only thing you can assume is
that, by the time your custom data files are executed, all the
database tables already will have been created.
.. admonition:: Initial SQL data and testing
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.
If you require data for a test case, you should add it using
either a :ref:`test fixture <topics-testing-fixtures>`, or
programmatically add it during the ``setUp()`` of your test case.
Database-backend-specific SQL data
----------------------------------
There's also a hook for backend-specific SQL data. For example, you
can have separate initial-data files for PostgreSQL and SQLite. For
each app, Django looks for a file called
``<app_label>/sql/<modelname>.<backend>.sql``, where ``<app_label>`` is
your app directory, ``<modelname>`` is the model's name in lowercase
and ``<backend>`` is the last part of the module name provided for the
:setting:`ENGINE <DATABASE-ENGINE>` in your settings file (e.g., if you have
defined a database with an :setting:`ENGINE <DATABASE-ENGINE>` value of
``django.db.backends.sqlite3``, Django will look for
``<app_label>/sql/<modelname>.sqlite3.sql``).
Backend-specific SQL data is executed before non-backend-specific SQL
data. For example, if your app contains the files ``sql/person.sql``
and ``sql/person.sqlite3.sql`` and you're installing the app on
SQLite, Django will execute the contents of
``sql/person.sqlite3.sql`` first, then ``sql/person.sql``.