From ef933f164350d8dffa422eeb9014ab60d3025f03 Mon Sep 17 00:00:00 2001 From: Gary Wilson Jr Date: Mon, 30 Mar 2009 19:54:27 +0000 Subject: [PATCH] Fixed a few class references in the model field docs. git-svn-id: http://code.djangoproject.com/svn/django/trunk@10207 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/ref/models/fields.txt | 33 ++++++++++++++++++--------------- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt index 1daf6e29408..62127884b62 100644 --- a/docs/ref/models/fields.txt +++ b/docs/ref/models/fields.txt @@ -45,11 +45,11 @@ booleans and dates. For both types of fields, you will also need to set :attr:`~Field.blank`). Avoid using :attr:`~Field.null` on string-based fields such as -:class:`CharField` and :class:`TextField` unless you have an excellent reason. -If a string-based field has ``null=True``, that means it has two possible values -for "no data": ``NULL``, and the empty string. In most cases, it's redundant to -have two possible values for "no data;" Django convention is to use the empty -string, not ``NULL``. +:class:`~django.db.models.CharField` and :class:`~django.db.models.TextField` +unless you have an excellent reason. If a string-based field has ``null=True``, +that means it has two possible values for "no data": ``NULL``, and the empty +string. In most cases, it's redundant to have two possible values for "no +data;" Django convention is to use the empty string, not ``NULL``. .. note:: @@ -142,8 +142,9 @@ documentation. Finally, note that choices can be any iterable object -- not necessarily a list or tuple. This lets you construct choices dynamically. But if you find yourself hacking :attr:`~Field.choices` to be dynamic, you're probably better off using a -proper database table with a :class:`ForeignKey`. :attr:`~Field.choices` is -meant for static data that doesn't change much, if ever. +proper database table with a :class:`~django.db.models.ForeignKey`. +:attr:`~Field.choices` is meant for static data that doesn't change much, if +ever. ``db_column`` ------------- @@ -219,10 +220,10 @@ Alternatively you can use plain text and If ``True``, this field is the primary key for the model. If you don't specify ``primary_key=True`` for any fields in your model, Django -will automatically add an :class:`IntegerField` to hold the primary key, so you -don't need to set ``primary_key=True`` on any of your fields unless you want to -override the default primary-key behavior. For more, see -:ref:`automatic-primary-key-fields`. +will automatically add an :class:`~django.db.models.IntegerField` to hold the +primary key, so you don't need to set ``primary_key=True`` on any of your +fields unless you want to override the default primary-key behavior. For more, +see :ref:`automatic-primary-key-fields`. ``primary_key=True`` implies :attr:`null=False ` and :attr:`unique=True `. Only one primary key is allowed on an object. @@ -239,16 +240,18 @@ you try to save a model with a duplicate value in a :attr:`~Field.unique` field, a :exc:`django.db.IntegrityError` will be raised by the model's :meth:`~django.db.models.Model.save` method. -This option is valid on all field types except :class:`ManyToManyField` and -:class:`FileField`. +This option is valid on all field types except +:class:`~django.db.models.ManyToManyField` and +:class:`~django.db.models.FileField`. ``unique_for_date`` ------------------- .. attribute:: Field.unique_for_date -Set this to the name of a :class:`DateField` or :class:`DateTimeField` to -require that this field be unique for the value of the date field. +Set this to the name of a :class:`~django.db.models.DateField` or +:class:`~django.db.models.DateTimeField` to require that this field be unique +for the value of the date field. For example, if you have a field ``title`` that has ``unique_for_date="pub_date"``, then Django wouldn't allow the entry of two