Added a db_constraint option to ForeignKeys.

This controls whether or not a database level cosntraint is created. This is useful in a few specialized circumstances, but in general should not be used!

2 files changed, 16 insertions, 0 deletions

diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 33ee05dd85..a4ae66d492 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -1051,6 +1051,19 @@ define the details of how the relation works.
     The field on the related object that the relation is to. By default, Django
     uses the primary key of the related object.
 
+.. attribute:: ForeignKey.db_constraint
+
+    Controls whether or not a constraint should be created in the database for
+    this foreign key. The default is ``True``, and that's almost certainly what
+    you want; setting this to ``False`` can be very bad for data integrity.
+    That said, here are some scenarios where you might want to do this:
+
+    * You have legacy data that is not valid.
+    * You're sharding your database.
+
+    If you use this, accessing a related object that doesn't exist will raise
+    its ``DoesNotExist`` exception.
+
 .. attribute:: ForeignKey.on_delete
 
     When an object referenced by a :class:`ForeignKey` is deleted, Django by
diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt
index 9594481b9f..8f1a4f375e 100644
--- a/docs/releases/1.6.txt
+++ b/docs/releases/1.6.txt
@@ -85,6 +85,9 @@ Minor features
   :class:`~django.http.HttpResponsePermanentRedirect` now provide an ``url``
   attribute (equivalent to the URL the response will redirect to).
 
+* Added the :attr:`django.db.models.ForeignKey.db_constraint`
+  option.
+
 Backwards incompatible changes in 1.6
 =====================================