From b55cde054ee7dd22f93c3522a8ddb1d04193bcac Mon Sep 17 00:00:00 2001 From: Alex Gaynor Date: Wed, 20 Feb 2013 11:27:32 -0800 Subject: 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 | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'docs/ref/models') 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 -- cgit v1.3