Opened 12 years ago

Closed 11 years ago

#1717 closed enhancement (fixed)

[patch] [magic-removal] add content-type back to the model (optionally)

Reported by: Ian@… Owned by: Adrian Holovaty
Component: Contrib apps Version:
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


The following adds the content type field back to the model.
It only adds it *IF* you have included the contenttypes app in your setting, so it won't affect the minimalist people who don't want content-types at all.

---   (revision 2766)
+++   (working copy)
@@ -1,5 +1,7 @@
 from django.db import models
+from django.db.models import signals
 from django.utils.translation import gettext_lazy as _
+from django.dispatch import dispatcher 
 class ContentTypeManager(models.Manager):
     def get_for_model(self, model):
@@ -47,3 +49,19 @@
         so code that calls this method should catch it.
         return self.model_class()._default_manager.get(**kwargs)
+class LazyContentType(object):
+    def __init__(self):
+        self._myContentType = None
+#        self._myModel = model
+    def __get__(self, cls, obj_type=None):
+        if self._myContentType is None:
+            self._myContentType = ContentType.objects.get_for_model( obj_type )
+        return self._myContentType
+def add_contenttypes(sender):
+    sender.model_ContentType= LazyContentType()
+dispatcher.connect(add_contenttypes, signal=signals.class_prepared)

Attachments (1)

content_type_model_cache.diff (1.3 KB) - added by Dave St.Germain <dcs@…> 11 years ago.
a simple cache for content types

Download all attachments as: .zip

Change History (10)

comment:1 Changed 12 years ago by Adrian Holovaty

Summary: [PATCH] [MAGIC-REMOVAL] add content-type back to the model (optionaly)[patch] [magic-removal] add content-type back to the model (optionally)

comment:2 Changed 12 years ago by Malcolm Tredinnick

So I think this patch should go in, since it is a big performance improvement when you need regular access to the content type. But every time I look at it I'm not completely sure of how we want to hook it into the model. Ian's suggestion of a model_ContentType does not fill me with happiness.

One non-option: we can't make it a default manager method (easily) becaues there is no guarantee about whether add_contenttypes() in this patch will be called before or after ensure_default_manager() in django.db.models.manager. So we may not even have a default manager when we want to hook this up.

  1. To be analagous to the 0.91 functionality we could stick a content_type attribute in the Options class, so you would refer to it as myInstance._meta.content_type, but we don't have many public access methods that require diving into _meta.
  2. We could put a get_content_type() method on the model itself, risking a name clash with a user method. This would probably just be an accessor to _meta.content_type anyway, though, so we could allow the user to rename it or something.
  3. We could do something like Luke and Ian are doing in Zyons and have a separate cache somewhere (attached to the ContentType module) and a django.utils function for retrieving this information. This would avoid any messing with the model itself, but would separate the function from the model it relates to.

Adrian: do you have any thoughts on this? If I had to pick one, I would go with option 2, but there are downsides to each one.

comment:3 Changed 12 years ago by anonymous

#2 gets my vote (If I had a vote)

for me (I use the content-type table alot) this is a big performance hog.

comment:4 Changed 12 years ago by Jacob

Resolution: wontfix
Status: newclosed

While I agree that the multiple redundant lookups on ContentType are a major problem, this isn't the right way to fix it. I'd prefer just to cache ContentType.objects.get_for_model() over hacking an optional app into the core.

So someone please submit a patch for that :)

Changed 11 years ago by Dave St.Germain <dcs@…>

a simple cache for content types

comment:5 Changed 11 years ago by Dave St.Germain <dcs@…>

Component: Core frameworkContrib apps
Resolution: wontfix
Status: closedreopened

comment:6 Changed 11 years ago by Jacob

Resolution: wontfix
Status: reopenedclosed

Please don't reopen tickets we've marked closed, and especially don't without an explanation!

comment:7 Changed 11 years ago by mir@…

Resolution: wontfix
Status: closedreopened

Jacob, Dave reopened because he submitted a patch. And you even asked for a patch. I don't think you actually want people to submit patches and then leaving the ticket closed, do you? ;-)

comment:8 Changed 11 years ago by Jacob

Yowza - I need to read more closely! I must have only noticed the reopen action... Dave, I'm *very* sorry!

comment:9 Changed 11 years ago by Jacob

Resolution: fixed
Status: reopenedclosed

Fixed in [4307].

Note: See TracTickets for help on using tickets.
Back to Top