mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2024-12-23 09:36:06 +00:00
Code Issues 25 Releases Wiki Activity

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

Browse Source 
Thanks Karen Tracey for the report.
This commit is contained in:
Tim Graham 2014-04-17 20:21:22 -04:00
parent 11e30b684d
commit a4acb80463
3 changed files with 20 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/howto/initial-data.txt
View File

@ -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

7
docs/internals/deprecation.txt
View File

@ -53,7 +53,8 @@ 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`.
@ -61,10 +62,6 @@ details on these changes.
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.

6
docs/releases/1.7.txt
View File

@ -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``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~