~ubuntu-branches/ubuntu/quantal/python-django/quantal

« back to all changes in this revision

Viewing changes to docs/ref/contrib/contenttypes.txt

  • Committer: Bazaar Package Importer
  • Author(s): Chris Lamb
  • Date: 2009-07-29 11:26:28 UTC
  • mfrom: (1.1.8 upstream) (4.1.5 sid)
  • Revision ID: james.westby@ubuntu.com-20090729112628-pg09ino8sz0sj21t
Tags: 1.1-1
* New upstream release.
* Merge from experimental:
  - Ship FastCGI initscript and /etc/default file in python-django's examples
    directory (Closes: #538863)
  - Drop "05_10539-sphinx06-compatibility.diff"; it has been applied
    upstream.
  - Bump Standards-Version to 3.8.2.

Show diffs side-by-side

added added

removed removed

Lines of Context:
177
177
    .. method:: models.ContentTypeManager.clear_cache()
178
178
 
179
179
        Clears an internal cache used by
180
 
        :class:`~django.contrib.contenttypes.models.ContentType>` to keep track
 
180
        :class:`~django.contrib.contenttypes.models.ContentType` to keep track
181
181
        of which models for which it has created
182
 
        :class:`django.contrib.contenttypes.models.ContentType>` instances. You
 
182
        :class:`django.contrib.contenttypes.models.ContentType` instances. You
183
183
        probably won't ever need to call this method yourself; Django will call
184
184
        it automatically when it's needed.
185
185
 
303
303
    >>> b.tags.all()
304
304
    [<TaggedItem: django>, <TaggedItem: python>]
305
305
 
306
 
If you don't add the reverse relationship, you can do the lookup manually::
 
306
Just as :class:`django.contrib.contenttypes.generic.GenericForeignKey`
 
307
accepts the names of the content-type and object-ID fields as
 
308
arguments, so too does ``GenericRelation``; if the model which has the
 
309
generic foreign key is using non-default names for those fields, you
 
310
must pass the names of the fields when setting up a
 
311
``GenericRelation`` to it. For example, if the ``TaggedItem`` model
 
312
referred to above used fields named ``content_type_fk`` and
 
313
``object_primary_key`` to create its generic foreign key, then a
 
314
``GenericRelation`` back to it would need to be defined like so::
 
315
 
 
316
    tags = generic.GenericRelation(TaggedItem, content_type_field='content_type_fk', object_id_field='object_primary_key')
 
317
 
 
318
Of course, if you don't add the reverse relationship, you can do the
 
319
same types of lookups manually::
307
320
 
308
321
    >>> b = Bookmark.objects.get(url='http://www.djangoproject.com/')
309
322
    >>> bookmark_type = ContentType.objects.get_for_model(b)
311
324
    ...                           object_id=b.id)
312
325
    [<TaggedItem: django>, <TaggedItem: python>]
313
326
 
 
327
Note that if the model with a :class:`~django.contrib.contenttypes.generic.GenericForeignKey`
 
328
that you're referring to uses a non-default value for ``ct_field`` or ``fk_field``
 
329
(e.g. the :mod:`django.contrib.comments` app uses ``ct_field="object_pk"``),
 
330
you'll need to pass ``content_type_field`` and ``object_id_field`` to
 
331
:class:`~django.contrib.contenttypes.generic.GenericRelation`.::
 
332
 
 
333
        comments = generic.GenericRelation(Comment, content_type_field="content_type", object_id_field="object_pk")
 
334
 
314
335
Note that if you delete an object that has a
315
336
:class:`~django.contrib.contenttypes.generic.GenericRelation`, any objects
316
337
which have a :class:`~django.contrib.contenttypes.generic.GenericForeignKey`
318
339
if a ``Bookmark`` object were deleted, any ``TaggedItem`` objects pointing at
319
340
it would be deleted at the same time.
320
341
 
 
342
Generic relations and aggregation
 
343
---------------------------------
 
344
 
 
345
:ref:`Django's database aggregation API <topics-db-aggregation`
 
346
doesn't work with a
 
347
:class:`~django.contrib.contenttypes.generic.GenericRelation`. For example, you
 
348
might be tempted to try something like::
 
349
 
 
350
    Bookmark.objects.aggregate(Count('tags'))
 
351
 
 
352
This will not work correctly, however. The generic relation adds extra filters
 
353
to the queryset to ensure the correct content type, but the ``aggregate`` method
 
354
doesn't take them into account. For now, if you need aggregates on generic
 
355
relations, you'll need to calculate them without using the aggregation API.
 
356
 
321
357
Generic relations in forms and admin
322
358
------------------------------------
323
359
 
324
 
:mod:`django.contrib.contenttypes.generic` provides both a 
 
360
:mod:`django.contrib.contenttypes.generic` provides both a
325
361
:class:`~django.contrib.contenttypes.generic.GenericInlineFormSet`
326
362
and :class:`~django.contrib.contenttypes.generic.GenericInlineModelAdmin`.
327
363
This enables the use of generic relations in forms and the admin. See the
340
376
        The name of the
341
377
        :class:`~django.contrib.contenttypes.models.ContentType` foreign key
342
378
        field on the model. Defaults to ``content_type``.
343
 
    
 
379
 
344
380
    .. attribute:: generic.GenericInlineModelAdmin.ct_fk_field
345
 
    
 
381
 
346
382
        The name of the integer field that represents the ID of the related
347
383
        object. Defaults to ``object_id``.