Ticket #8883: topics-db-models.diff
| File topics-db-models.diff, 7.6 KB (added by , 16 years ago) |
|---|
-
docs/topics/db/models.txt
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 a345 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 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 onthe target model (this would be ``Person`` in our example). If you410 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 onthe source model (this would be ``Group`` in our example). If you414 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 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 start429 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 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 - you461 need to specify all the detail for the relationship required by the462 Membership table. The simple ``add``, ``create`` and assignment calls460 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 table466 i s 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 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 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 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, just542 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 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 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 Python742 :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 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 an822 attribute. If a child class does not declare dits 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 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 ind vidually. The inheritance897 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 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 explicit y set it to be empty::946 ordering, you can explicitly disable it:: 949 947 950 948 class ChildModel(ParentModel): 951 949 ... … … 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 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