Fixed #17929 -- Improved tutorial wording and capitalization.

   the :ref:`DRY Principle <dry>`. The goal is to define your data model in one

   place and automatically derive things from it.

In our simple poll app, we'll create two models: polls and choices. A poll has

a question and a publication date. A choice has two fields: the text of the

choice and a vote tally. Each choice is associated with a poll.

In our simple poll app, we'll create two models: ``Poll`` and ``Choice``.

A ``Poll`` has a question and a publication date. A ``Choice`` has two fields:

the text of the choice and a vote tally. Each ``Choice`` is associated with a

``Poll``.

These concepts are represented by simple Python classes. Edit the

:file:`polls/models.py` file so it looks like this::

    class Choice(models.Model):

        poll = models.ForeignKey(Poll)

        choice = models.CharField(max_length=200)

        choice_text = models.CharField(max_length=200)

        votes = models.IntegerField()

The code is straightforward. Each model is represented by a class that

schema, but in validation, as we'll soon see.

Finally, note a relationship is defined, using

:class:`~django.db.models.ForeignKey`. That tells Django each Choice is related

to a single Poll. Django supports all the common database relationships:

:class:`~django.db.models.ForeignKey`. That tells Django each ``Choice`` is related

to a single ``Poll``. Django supports all the common database relationships:

many-to-ones, many-to-manys and one-to-ones.

.. _`Python path`: http://docs.python.org/tutorial/modules.html#the-module-search-path

is able to:

* Create a database schema (``CREATE TABLE`` statements) for this app.

* Create a Python database-access API for accessing Poll and Choice objects.

* Create a Python database-access API for accessing ``Poll`` and ``Choice`` objects.

But first we need to tell our project that the ``polls`` app is installed.

    CREATE TABLE "polls_choice" (

        "id" serial NOT NULL PRIMARY KEY,

        "poll_id" integer NOT NULL REFERENCES "polls_poll" ("id") DEFERRABLE INITIALLY DEFERRED,

        "choice" varchar(200) NOT NULL,

        "choice_text" varchar(200) NOT NULL,

        "votes" integer NOT NULL

    );

    COMMIT;

    class Choice(models.Model):

        # ...

        def __unicode__(self):

            return self.choice

            return self.choice_text

It's important to add :meth:`~django.db.models.Model.__unicode__` methods to

your models, not only for your own sanity when dealing with the interactive

    True

    # Give the Poll a couple of Choices. The create call constructs a new

    # choice object, does the INSERT statement, adds the choice to the set

    # Choice object, does the INSERT statement, adds the choice to the set

    # of available choices and returns the new Choice object. Django creates

    # a set to hold the "other side" of a ForeignKey relation

    # (e.g. a poll's choices) which can be accessed via the API.

    []

    # Create three choices.

    >>> p.choice_set.create(choice='Not much', votes=0)

    >>> p.choice_set.create(choice_text='Not much', votes=0)

    <Choice: Not much>

    >>> p.choice_set.create(choice='The sky', votes=0)

    >>> p.choice_set.create(choice_text='The sky', votes=0)

    <Choice: The sky>

    >>> c = p.choice_set.create(choice='Just hacking again', votes=0)

    >>> c = p.choice_set.create(choice_text='Just hacking again', votes=0)

    # Choice objects have API access to their related Poll objects.

    >>> c.poll

    [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]

    # Let's delete one of the choices. Use delete() for that.

    >>> c = p.choice_set.filter(choice__startswith='Just hacking')

    >>> c = p.choice_set.filter(choice_text__startswith='Just hacking')

    >>> c.delete()

For more information on model relations, see :doc:`Accessing related objects