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

[Ian@…]

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.

Index: models.py
===================================================================
--- models.py   (revision 2766)
+++ models.py   (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)

[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.

[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.

[Jacob]

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 :)

[Dave St.Germain <dcs@…>]

a simple cache for content types

[Jacob]

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

[mir@…]

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? ;-)

[Jacob]

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

[Jacob]

Fixed in [4307].