Opened 19 years ago
Closed 18 years ago
#1717 closed enhancement (fixed)
[patch] [magic-removal] add content-type back to the model (optionally)
Reported by: | 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: | no | UI/UX: | no |
Description
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)
Attachments (1)
Change History (10)
comment:1 by , 19 years ago
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 by , 18 years ago
comment:3 by , 18 years ago
#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 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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 :)
comment:5 by , 18 years ago
Component: | Core framework → Contrib apps |
---|---|
Resolution: | wontfix |
Status: | closed → reopened |
comment:6 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
Please don't reopen tickets we've marked closed, and especially don't without an explanation!
comment:7 by , 18 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
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 by , 18 years ago
Yowza - I need to read more closely! I must have only noticed the reopen action... Dave, I'm *very* sorry!
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.
myInstance._meta.content_type
, but we don't have many public access methods that require diving into _meta.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.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.