Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Fixed #8883 -- Fixed some glitches in model reference. Thanks, arien

git-svn-id: http://code.djangoproject.com/svn/django/trunk@8974 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit a0875bcc898b41208d20f07c2095193e9ad5298d 1 parent 83dd70f
Adrian Holovaty authored September 06, 2008

Showing 1 changed file with 25 additions and 28 deletions. Show diff stats Hide diff stats

  1. 53  docs/topics/db/models.txt
53  docs/topics/db/models.txt
@@ -342,7 +342,7 @@ Generally, :class:`~django.db.models.ManyToManyField` instances should go in the
342 342
 object that's going to be edited in the admin interface, if you're using
343 343
 Django's admin. In the above example, ``toppings`` is in ``Pizza`` (rather than
344 344
 ``Topping`` having a ``pizzas`` :class:`~django.db.models.ManyToManyField` )
345  
-because it's more natural to think about a ``Pizza`` having toppings than a
  345
+because it's more natural to think about a pizza having toppings than a
346 346
 topping being on multiple pizzas. The way it's set up above, the ``Pizza`` admin
347 347
 form would let users select the toppings.
348 348
 
@@ -407,11 +407,11 @@ explicit declaration defines how the two models are related.
407 407
 There are a few restrictions on the intermediate model:
408 408
 
409 409
     * Your intermediate model must contain one - and *only* one - foreign key
410  
-      on the target model (this would be ``Person`` in our example). If you
  410
+      to the target model (this would be ``Person`` in our example). If you
411 411
       have more than one foreign key, a validation error will be raised.
412 412
   
413 413
     * Your intermediate model must contain one - and *only* one - foreign key 
414  
-      on the source model (this would be ``Group`` in our example). If you
  414
+      to the source model (this would be ``Group`` in our example). If you
415 415
       have more than one foreign key, a validation error will be raised.
416 416
 
417 417
     * The only exception to this is a model which has a many-to-many
@@ -426,7 +426,7 @@ There are a few restrictions on the intermediate model:
426 426
       :ref:`the model field reference <manytomany-arguments>`).
427 427
 
428 428
 Now that you have set up your :class:`~django.db.models.ManyToManyField` to use
429  
-your intermediary model (Membership, in this case), you're ready to start
  429
+your intermediary model (``Membership``, in this case), you're ready to start
430 430
 creating some many-to-many relationships. You do this by creating instances of
431 431
 the intermediate model::
432 432
     
@@ -457,13 +457,13 @@ or assignment (i.e., ``beatles.members = [...]``) to create relationships::
457 457
     # AND NEITHER WILL THIS
458 458
     >>> beatles.members = [john, paul, ringo, george]
459 459
     
460  
-Why? You can't just create a relationship between a Person and a Group - you
461  
-need to specify all the detail for the relationship required by the
462  
-Membership table. The simple ``add``, ``create`` and assignment calls
  460
+Why? You can't just create a relationship between a ``Person`` and a ``Group``
  461
+- you need to specify all the detail for the relationship required by the
  462
+``Membership`` model. The simple ``add``, ``create`` and assignment calls
463 463
 don't provide a way to specify this extra detail. As a result, they are
464 464
 disabled for many-to-many relationships that use an intermediate model.
465  
-The only way to create a many-to-many relationship with an intermediate table
466  
-is to create instances of the intermediate model.
  465
+The only way to create this type of relationship is to create instances of the
  466
+intermediate model.
467 467
 
468 468
 The ``remove`` method is disabled for similar reasons. However, the
469 469
 ``clear()`` method can be used to remove all many-to-many relationships
@@ -481,8 +481,7 @@ many-to-many-related model::
481 481
     >>> Groups.objects.filter(person__name__startswith='Paul')
482 482
     [<Group: The Beatles>]
483 483
 
484  
-As you are using an intermediate table, you can also query on the attributes 
485  
-of the intermediate model::
  484
+As you are using an intermediate model, you can also query on its attributes::
486 485
 
487 486
     # Find all the members of the Beatles that joined after 1 Jan 1961
488 487
     >>> Person.objects.filter(
@@ -518,9 +517,7 @@ As with :class:`~django.db.models.ForeignKey`, a
518 517
 :ref:`recursive relationship <recursive-relationships>`
519 518
 can be defined and
520 519
 :ref:`references to as-yet undefined models <lazy-relationships>`
521  
-can be made; see
522  
-:class:`the model field reference <django.db.models.fields.OneToOneField>`
523  
-for details.
  520
+can be made; see :ref:`the model field reference <ref-onetoone>` for details.
524 521
 
525 522
 .. seealso::
526 523
 
@@ -542,7 +539,7 @@ Thus, it's now possible to have multiple fields of type
542 539
 Models across files
543 540
 -------------------
544 541
 
545  
-It's perfectly OK to relate a model to one from another app. To do this, just
  542
+It's perfectly OK to relate a model to one from another app. To do this,
546 543
 import the related model at the top of the model that holds your model. Then,
547 544
 just refer to the other model class wherever needed. For example::
548 545
 
@@ -626,6 +623,7 @@ model.
626 623
 For example, this model has a few custom methods::
627 624
 
628 625
     from django.contrib.localflavor.us.models import USStateField
  626
+
629 627
     class Person(models.Model):
630 628
         first_name = models.CharField(max_length=50)
631 629
         last_name = models.CharField(max_length=50)
@@ -741,8 +739,8 @@ the resulting rows. For example::
741 739
         row = cursor.fetchone()
742 740
         return row
743 741
 
744  
-:class:`connection <django.db.backends.DatabaseWrapper>` and
745  
-:class:`<django.db.backends.CursorWrapper>` mostly implement the standard Python
  742
+:class:`connection <django.db.backends.DatabaseWrapper>` and :class:`cursor
  743
+<django.db.backends.CursorWrapper>` mostly implement the standard Python
746 744
 DB-API -- see :pep:`249` -- with the addition of Django's :ref:`transaction
747 745
 handling <topics-db-transactions>`. If you're not familiar with the Python
748 746
 DB-API, note that the SQL statement in :meth:`cursor.execute()
@@ -818,8 +816,8 @@ still only creating one database table per child model at the database level.
818 816
 ~~~~~~~~~~~~~~~~~~~~
819 817
 
820 818
 When an abstract base class is created, Django makes any :ref:`Meta <meta-options>`
821  
-inner class you declared on the base class available as an
822  
-attribute. If a child class does not declared its own :ref:`Meta <meta-options>`
  819
+inner class you declared in the base class available as an
  820
+attribute. If a child class does not declare its own :ref:`Meta <meta-options>`
823 821
 class, it will inherit the parent's :ref:`Meta <meta-options>`. If the child wants to
824 822
 extend the parent's :ref:`Meta <meta-options>` class, it can subclass it. For example::
825 823
 
@@ -896,9 +894,9 @@ Multi-table inheritance
896 894
 
897 895
 The second type of model inheritance supported by Django is when each model in
898 896
 the hierarchy is a model all by itself. Each model corresponds to its own
899  
-database table and can be queried and created indvidually. The inheritance
  897
+database table and can be queried and created individually. The inheritance
900 898
 relationship introduces links between the child model and each of its parents
901  
-(via an automatically-created :class`~django.db.models.fields.OneToOneField`).
  899
+(via an automatically-created :class:`~django.db.models.fields.OneToOneField`).
902 900
 For example::
903 901
 
904 902
     class Place(models.Model):
@@ -945,7 +943,7 @@ parent: if the child does not specify an :attr:`django.db.models.Options.orderin
945 943
 :attr:`django.db.models.Options.get_latest_by` attribute, it will inherit these from its parent.
946 944
 
947 945
 If the parent has an ordering and you don't want the child to have any natural
948  
-ordering, you can explicity set it to be empty::
  946
+ordering, you can explicitly disable it::
949 947
 
950 948
     class ChildModel(ParentModel):
951 949
         ...
@@ -974,8 +972,7 @@ subclass with a :class:`~django.db.models.fields.ManyToManyField`::
974 972
 
975 973
     class Supplier(Place):
976 974
         # Must specify related_name on all relations.
977  
-        customers = models.ManyToManyField(Restaurant,
978  
-                related_name='provider')
  975
+        customers = models.ManyToManyField(Restaurant, related_name='provider')
979 976
 
980 977
 
981 978
 Specifying the parent link field
@@ -994,10 +991,10 @@ Multiple inheritance
994 991
 
995 992
 Just as with Python's subclassing, it's possible for a Django model to inherit
996 993
 from multiple parent models. Keep in mind that normal Python name resolution
997  
-rules apply. The first base class that a particular name appears in (e.g.
998  
-:ref:`Meta <meta-options>`) will be the one that is used; for example,
999  
-his means that if multiple parents contain a :ref:`Meta <meta-options>` class, only
1000  
-the first one is going to be used, and all others will be ignored.
  994
+rules apply. The first base class that a particular name (e.g. :ref:`Meta
  995
+<meta-options>`) appears in will be the one that is used; for example, this
  996
+means that if multiple parents contain a :ref:`Meta <meta-options>` class,
  997
+only the first one is going to be used, and all others will be ignored.
1001 998
 
1002 999
 Generally, you won't need to inherit from multiple parents. The main use-case
1003 1000
 where this is useful is for "mix-in" classes: adding a particular extra

0 notes on commit a0875bc

Please sign in to comment.
Something went wrong with that request. Please try again.