Removed support for custom SQL per deprecation timeline.

9 files changed, 5 insertions, 132 deletions

diff --git a/docs/howto/initial-data.txt b/docs/howto/initial-data.txt
index 6b40c5a5d8..ac5839022d 100644
--- a/docs/howto/initial-data.txt
+++ b/docs/howto/initial-data.txt
@@ -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``.
diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt
index dc34e8765c..e94e0ed16c 100644
--- a/docs/intro/tutorial01.txt
+++ b/docs/intro/tutorial01.txt
@@ -543,9 +543,7 @@ Now, run :djadmin:`migrate` again to create those model tables in your database:
       Apply all migrations: polls
     Synchronizing apps without migrations:
       Creating tables...
-      Installing custom SQL...
       Installing indexes...
-    Installed 0 object(s) from 0 fixture(s)
     Running migrations:
       Applying polls.0001_initial... OK
 
diff --git a/docs/man/django-admin.1 b/docs/man/django-admin.1
index f683742a94..994c95c816 100644
--- a/docs/man/django-admin.1
+++ b/docs/man/django-admin.1
@@ -84,9 +84,6 @@ given model module name(s).
 .BI "sqlclear [" "app_label ..." "]"
 Prints the DROP TABLE SQL statements for the given app name(s).
 .TP
-.BI "sqlcustom [" "app_label ..." "]"
-Prints the custom SQL statements for the given app name(s).
-.TP
 .BI "sqlflush [" "app_label ..." "]"
 Prints the SQL statements that would be executed for the "flush" command.
 .TP
diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt
index 29c9537dad..a437c0f764 100644
--- a/docs/ref/django-admin.txt
+++ b/docs/ref/django-admin.txt
@@ -989,9 +989,6 @@ sqlall <app_label app_label ...>
 
 Prints the CREATE TABLE and initial-data SQL statements for the given app name(s).
 
-Refer to the description of :djadmin:`sqlcustom` for an explanation of how to
-specify initial data.
-
 The :djadminopt:`--database` option can be used to specify the database for
 which to print the SQL.
 
@@ -1012,30 +1009,6 @@ Prints the DROP TABLE SQL statements for the given app name(s).
 The :djadminopt:`--database` option can be used to specify the database for
 which to print the SQL.
 
-sqlcustom <app_label app_label ...>
------------------------------------
-
-.. django-admin:: sqlcustom
-
-Prints the custom SQL statements for the given app name(s).
-
-For each model in each specified app, this command looks for the file
-``<app_label>/sql/<modelname>.sql``, where ``<app_label>`` is the given app
-name and ``<modelname>`` is the model's name in lowercase. For example, if you
-have an app ``news`` that includes a ``Story`` model, ``sqlcustom`` will
-attempt to read a file ``news/sql/story.sql`` and append it to the output of
-this command.
-
-Each of the SQL files, if given, is expected to contain valid SQL. The SQL
-files are piped directly into the database after all of the models'
-table-creation statements have been executed. Use this SQL hook to make any
-table modifications, or insert any SQL functions into the database.
-
-Note that the order in which the SQL files are processed is undefined.
-
-The :djadminopt:`--database` option can be used to specify the database for
-which to print the SQL.
-
 sqldropindexes <app_label app_label ...>
 ----------------------------------------
 
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 8604137afe..39d728bbce 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -1295,8 +1295,7 @@ The possible values for :attr:`~ForeignKey.on_delete` are found in
 
     Take no action. If your database backend enforces referential
     integrity, this will cause an :exc:`~django.db.IntegrityError` unless
-    you manually add an SQL ``ON DELETE`` constraint to the database field
-    (perhaps using :ref:`initial sql<initial-sql>`).
+    you manually add an SQL ``ON DELETE`` constraint to the database field.
 
 .. attribute:: ForeignKey.swappable
 
diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt
index 70101ec946..040190241c 100644
--- a/docs/releases/1.7.txt
+++ b/docs/releases/1.7.txt
@@ -738,7 +738,7 @@ Management Commands
 * :djadmin:`collectstatic` command with symlink option is now supported on
   Windows NT 6 (Windows Vista and newer).
 
-* :ref:`initial-sql` now works better if the sqlparse_ Python library is
+* Initial SQL data now works better if the sqlparse_ Python library is
   installed.
 
   Note that it's deprecated in favor of the
@@ -1517,8 +1517,8 @@ Custom SQL location for models package
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Previously, if models were organized in a package (``myapp/models/``) rather
-than simply ``myapp/models.py``, Django would look for :ref:`initial SQL data
-<initial-sql>` in ``myapp/models/sql/``. This bug has been fixed so that Django
+than simply ``myapp/models.py``, Django would look for initial SQL data in
+``myapp/models/sql/``. This bug has been fixed so that Django
 will search ``myapp/sql/`` as documented. After this issue was fixed, migrations
 were added which deprecates initial SQL data. Thus, while this change still
 exists, the deprecation is irrelevant as the entire feature will be removed in
diff --git a/docs/spelling_wordlist b/docs/spelling_wordlist
index 26bb3a5a65..498f03efbd 100644
--- a/docs/spelling_wordlist
+++ b/docs/spelling_wordlist
@@ -585,7 +585,6 @@ Springmeyer
 sql
 sqlall
 sqlclear
-sqlcustom
 sqldropindexes
 sqlflush
 sqlindexes
diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt
index e1d13457b7..9c56574857 100644
--- a/docs/topics/migrations.txt
+++ b/docs/topics/migrations.txt
@@ -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
 
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index 1f794701be..3fabf63c44 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -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`