  
  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.
  
  ``db_column``
  -------------
  
  .. attribute:: Field.db_column
 
</s> remove 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.
 </s> add 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. </s> remove :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``.
 </s> add :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``. </s> remove This option is valid on all field types except :class:`ManyToManyField` and
:class:`FileField`.
 </s> add This option is valid on all field types except
:class:`~django.db.models.ManyToManyField` and
:class:`~django.db.models.FileField`. </s> remove 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`.
 </s> add 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`.
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.
  
  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:`~django.db.models.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``
  -------------
  
  .. attribute:: Field.db_column
keep keep keep keep replace replace keep keep keep keep keep
 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