From 4aa089a9a9504c4a833eee8161be013206da5d15 Mon Sep 17 00:00:00 2001 From: Tim Graham Date: Fri, 26 Dec 2014 13:56:08 -0500 Subject: Removed support for custom SQL per deprecation timeline. --- docs/howto/initial-data.txt | 84 +-------------------------------------------- 1 file changed, 1 insertion(+), 83 deletions(-) (limited to 'docs/howto/initial-data.txt') 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 ` 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 `. - -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/.sql``, -in your app directory, where ```` 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 `. Refer to the :doc:`manage.py -documentation ` 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 `, 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 -``/sql/..sql``, where ```` is -your app directory, ```` is the model's name in lowercase -and ```` is the last part of the module name provided for the -:setting:`ENGINE ` in your settings file (e.g., if you have -defined a database with an :setting:`ENGINE ` value of -``django.db.backends.sqlite3``, Django will look for -``/sql/.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``. -- cgit v1.3