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!

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

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