Permalink
Browse files

Fixed #22444 -- Marked initial SQL/fixture loading as deprecated.

Thanks Karen Tracey for the report.
  • Loading branch information...
timgraham committed Apr 18, 2014
1 parent 11e30b6 commit a4acb804634af17cfd9ee7070ec3865d7cc2a7a3
Showing with 20 additions and 7 deletions.
  1. +14 −0 docs/howto/initial-data.txt
  2. +2 −5 docs/internals/deprecation.txt
  3. +4 −2 docs/releases/1.7.txt
@@ -77,6 +77,13 @@ again, you'll wipe out any changes you've made.
Automatically loading initial data fixtures
-------------------------------------------
+.. deprecated:: 1.7
+
+ If an application uses migrations, there is no automatic loading of
+ fixtures. Since migrations will be required for applications in Django 1.9,
+ this behavior is considered deprecated. If you want to load initial data
+ for an app, consider doing it in a migration.
+
If you create a fixture named ``initial_data.[xml/yaml/json]``, that fixture will
be loaded every time you run :djadmin:`migrate`. This is extremely convenient,
but be careful: remember that the data will be refreshed *every time* you run
@@ -103,6 +110,13 @@ directories.
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 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
@@ -53,18 +53,15 @@ details on these changes.
and all table/schema editing will be moved to be via ``SchemaEditor`` instead.
* The legacy method of syncing apps without migrations will be removed,
- and migrations will become compulsory for all apps.
+ and migrations will become compulsory for all apps. This includes automatic
+ loading of fixtures and support for initial SQL data.
* All models will need to be defined inside an installed application or
declare an explicit :attr:`~django.db.models.Options.app_label`.
Furthermore, it won't be possible to import them before their application
is loaded. In particular, it won't be possible to import models inside
the root package of their application.
-* If models are organized in a package, Django will no longer look for
- :ref:`initial SQL data<initial-sql>` in ``myapp/models/sql/``. Move your
- custom SQL files to ``myapp/sql/``.
-
* The model and form ``IPAddressField`` will be removed.
* ``AppCommand.handle_app()`` will no longer be supported.
View
@@ -1307,8 +1307,10 @@ 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
-will search ``myapp/sql/`` as documented. The old location will continue to
-work until Django 1.9.
+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
+Django 1.9.
Reorganization of ``django.contrib.sites``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0 comments on commit a4acb80

Please sign in to comment.