Django: Ticket Queryhttps://code.djangoproject.com/query?status=!closed&keywords=~ip&order=priority
The Web framework for perfectionists with deadlines.en-USDjangohttps://www.djangoproject.com/s/img/site/hdr_logo.gifhttps://code.djangoproject.com/query?status=!closed&keywords=~ip&order=priority
Trac 1.0.7https://code.djangoproject.com/ticket/5797
https://code.djangoproject.com/ticket/5797#5797: decorator_from_middleware can cause middleware hooks to run out of correct order.Mon, 22 Oct 2007 21:15:11 GMTjdunck<p>
cache_page, gzip_page, and conditional_page all use decorator_from_middleware.
</p>
<p>
decorator_from_middleware wraps the view function to simulate middleware being run on a per-view basis.
</p>
<p>
Here's the interesting bit:
</p>
<pre class="wiki"> def _wrapped_view(request, *args, **kwargs):
if hasattr(middleware, 'process_request'):
result = middleware.process_request(request)
if result is not None:
return result
if hasattr(middleware, 'process_view'):
result = middleware.process_view(request, view_func, *args, **kwargs)
if result is not None:
return result
try:
response = view_func(request, *args, **kwargs)
except Exception, e:
if hasattr(middleware, 'process_exception'):
result = middleware.process_exception(request, e)
if result is not None:
return result
raise
if hasattr(middleware, 'process_response'):
result = middleware.process_response(request, response)
if result is not None:
return result
return response
</pre><p>
The problem is that middleware's order is important. Suppose two middleware decorators, A and B, are applied to the same view.
</p>
<p>
The normal flow of middleware processing would be: A.process_request, B.process_request, A.process_view, B.process_view, view, B.process_response, A.process_response.
</p>
<p>
The flow of the *decorated execution* is this: A.process_request, A.process_view, B.process_request, B.process_view, view, B.process_response, A.process_response.
</p>
<p>
This is not yet a real-world issue as far as I know, but seems to be a lurking problem. I think the only reason it hasn't surfaced is that view decorators are fairly uncommon. I don't see a simple way to fix this.
</p>
Resultshttps://code.djangoproject.com/ticket/5797#changeloghttps://code.djangoproject.com/ticket/10961
https://code.djangoproject.com/ticket/10961#10961: Allow users to override forward and reverse relationships on proxy models with !ForeignKey fields.Thu, 30 Apr 2009 02:27:48 GMTmrmachine<p>
I have a few generic models with foreign keys (simplified for this example):
</p>
<pre class="wiki">class Country(turbia_models.Model):
name = turbia_models.CharField(max_length=50, unique=True)
class State(turbia_models.Model):
name = turbia_models.CharField(max_length=50)
country = models.ForeignKey(Country)
class Region(turbia_models.Model):
name = turbia_models.CharField(max_length=50)
state = models.ForeignKey(State)
class Suburb(turbia_models.Model):
name = turbia_models.CharField(max_length=50)
region = models.ForeignKey(Region)
</pre><p>
I want to create proxy models for each of these when used with particular applications:
</p>
<pre class="wiki">class Venue(models.Model):
name = models.CharField(max_length=50)
slug = models.SlugField()
suburb = models.ForeignKey(Suburb)
class CountryProxy(Country):
class Meta:
proxy = True
@property
def venue_set(self):
return Venue.objects.filter(suburb__region__state__country=self)
def get_absolute_url(self):
return '/directory/%s/' % self.slug
class StateProxy(State):
class Meta:
proxy = True
@property
def venue_set(self):
return Venue.objects.filter(suburb__region__state=self)
def get_absolute_url(self):
return '%s%s/' % (self.country.get_absolute_url(), self.slug)
class RegionProxy(Region):
class Meta:
proxy = True
@property
def venue_set(self):
return Venue.objects.filter(suburb__region=self)
def get_absolute_url(self):
return '%s%s/' % (self.state.get_absolute_url(), self.slug)
class SuburbProxy(Suburb):
class Meta:
proxy = True
@property
def venue_set(self):
return Venue.objects.filter(suburb=self)
def get_absolute_url(self):
return '%s%s/' % (self.region.get_absolute_url(), self.slug)
</pre><p>
This works if I never use the ForeignKey fields or reverse relationship managers to get related objects. E.g. if <tt>state</tt> is a StateProxy object and I try <tt>state.country</tt>, I'll end up with a !Country object instead of a CountryProxy object. Likewise if <tt>country</tt> is a CountryProxy object and I try <tt>country.state_set.all()</tt>, I'll end up with a queryset of !State objects instead of StateProxy objects.
</p>
<p>
This can be worked around with queries like <tt>Country.objects.get(pk=state.country.pk)</tt> and <tt>State.objects.filter(country=country)</tt>, but this kinda defeats the purpose of the ORM, and is not practical inside templates.
</p>
<p>
Where you should be able to just pass a single CountryProxy object to your template and do:
</p>
<pre class="wiki">&lt;h1&gt;{{ country }}&lt;/h1&gt;
{% for state in country.state_set.all %}
&lt;h2&gt;{{ state }}&lt;/h2&gt;
{% for region in state.region_set.all %}
&lt;h3&gt;{{ region }}&lt;/h3&gt;
&lt;p&gt;
{% for suburb in region.suburb_set.all %}
&lt;a href="{{ suburb.get_absolute_url }}"&gt;{{ suburb }}&lt;/a&gt;&lt;br&gt;
{% endfor %}
&lt;/p&gt;
{% endfor %}
{% endfor %}
</pre><p>
You need to pass all these objects and querysets from the view into the template context in some kind of nested structure.
</p>
<pre class="wiki">def directory(request, slug):
country = get_object_or_404(CountryProxy, slug=slug)
state_data = ((state, (
(region, SuburbProxy.objects.filter(region=region)) for region in RegionProxy.objects.filter(state=state)
)) for state in StateProxy.objects.filter(country=country))
render_to_response('directory.html', {'country': country, 'data': data})
</pre><p>
and:
</p>
<pre class="wiki">&lt;h1&gt;{{ country }}&lt;/h1&gt;
{% for state, region_data in state_data %}
&lt;h2&gt;{{ state }}&lt;/h2&gt;
{% for region, suburb_set in region_data %}
&lt;h3&gt;{{ region }}&lt;/h3&gt;
&lt;p&gt;
{% for suburb in suburb_set %}
&lt;a href="{{ suburb.get_absolute_url }}"&gt;{{ suburb }}&lt;/a&gt;&lt;br&gt;
{% endfor %}
&lt;/p&gt;
{% endfor %}
{% endfor %}
</pre>Resultshttps://code.djangoproject.com/ticket/10961#changeloghttps://code.djangoproject.com/ticket/14370
https://code.djangoproject.com/ticket/14370#14370: Adding support for Autocomplete in contrib.adminThu, 30 Sep 2010 23:36:44 GMTtyrion<p>
I've tried to implement Autocomplete for contrib.admin using jQuery UI Autocomplete.<br />
Here's the code: <a class="ext-link" href="http://bitbucket.org/tyrion/django"><span class="icon">​</span>http://bitbucket.org/tyrion/django</a> <br />
Here's a live demo: <a class="ext-link" href="http://djangoac.tyrion.mx/admin/"><span class="icon">​</span>http://djangoac.tyrion.mx/admin/</a> (login with test/test).
(It supports both <a class="wiki" href="https://code.djangoproject.com/wiki/ForeignKey">ForeignKey</a> and ManyToMany).
</p>
<p>
I don't know if I should attach the complete patch here. It's kinda big (I included jquery-ui), however you can see it online at <a class="ext-link" href="http://bitbucket.org/tyrion/django/changeset/04488ec05e92"><span class="icon">​</span>http://bitbucket.org/tyrion/django/changeset/04488ec05e92</a> ).
</p>
<p>
Now it's implemented using an "autocomplete_fields" attribute which is a dict (field:related_fields):
</p>
<div class="code"><pre><span class="k">class</span> <span class="nc">MyModelAdmin</span><span class="p">(</span>admin<span class="o">.</span>ModelAdmin<span class="p">):</span>
autocomplete_fields <span class="o">=</span> <span class="p">{</span><span class="s">'user'</span><span class="p">:</span> <span class="p">(</span><span class="s">'username'</span><span class="p">,</span> <span class="s">'email'</span><span class="p">)}</span>
</pre></div><p>
But because I've been asked:
</p>
<pre class="wiki">&lt;jezdez&gt; tyrion-mx: what about making the autocomplete_fields a dict of dicts, to be able to specify additional options for the autocompletion, e.g. number of search results or a custom label function?
</pre><p>
I've written this patch (for my code) <a class="ext-link" href="http://dpaste.com/hold/251220/"><span class="icon">​</span>http://dpaste.com/hold/251220/</a>
that let's you control the "value" (what is displayed in the input), "label" (what is displayed in the dropdown) and "limit" (max number of results) properties.
</p>
<p>
With it a modeladmin could look something like this:
</p>
<div class="code"><pre><span class="k">class</span> <span class="nc">DummyAdmin</span><span class="p">(</span>admin<span class="o">.</span>ModelAdmin<span class="p">):</span>
autocomplete_fields <span class="o">=</span> <span class="nb">dict</span><span class="p">(</span>
user1 <span class="o">=</span> <span class="nb">dict</span><span class="p">(</span>
fields <span class="o">=</span> <span class="p">(</span><span class="s">'username'</span><span class="p">,</span> <span class="s">'email'</span><span class="p">),</span>
value <span class="o">=</span> <span class="s">'username'</span><span class="p">,</span>
limit <span class="o">=</span> <span class="mi">10</span><span class="p">,</span>
<span class="p">),</span>
friends <span class="o">=</span> <span class="nb">dict</span><span class="p">(</span>
fields <span class="o">=</span> <span class="p">(</span><span class="s">'username'</span><span class="p">,</span> <span class="s">'email'</span><span class="p">),</span>
label <span class="o">=</span> <span class="s">u'</span><span class="si">%(first_name)s</span><span class="s"> </span><span class="si">%(last_name)s</span><span class="s">'</span><span class="p">,</span>
value <span class="o">=</span> <span class="s">'email'</span><span class="p">,</span>
<span class="p">),</span>
<span class="p">)</span>
</pre></div><p>
In that case "value" and "label" can be either a function, a fieldname or a string like <tt>u'%(username)s "%(email)s"'</tt>.
</p>
Resultshttps://code.djangoproject.com/ticket/14370#changeloghttps://code.djangoproject.com/ticket/15881
https://code.djangoproject.com/ticket/15881#15881: FilteredSelectMultiple does not respect orderThu, 21 Apr 2011 18:27:16 GMTbmihelac<p>
WIth filter_horizontal and filter_vertical admin options moving items between available and chosen, these items would be moved to the end of respecting lists.
</p>
<p>
I believe it would be useful and not so hard to preserve original sort order.
</p>
Resultshttps://code.djangoproject.com/ticket/15881#changeloghttps://code.djangoproject.com/ticket/16260
https://code.djangoproject.com/ticket/16260#16260: Ability to change dismissRelatedLookupPopup on custom callback functionWed, 15 Jun 2011 01:40:13 GMTalekam<p>
The best solution for some cases for customizing admin is put some links with showRelatedObjectLookupPopup javascript function on admin changelist, but after user choose the object, custom javascript function must be called instead of dismissRelatedLookupPopup javascript function.
</p>
<p>
Execution of dismissRelatedLookupPopup is hard coded in python code now. The easiest way to implement use case described higher is adding new GET argument "_callback" to changelist view.
</p>
Resultshttps://code.djangoproject.com/ticket/16260#changeloghttps://code.djangoproject.com/ticket/16281
https://code.djangoproject.com/ticket/16281#16281: ContentType.get_object_for_this_type using wrong database for creating objectThu, 16 Jun 2011 09:29:37 GMTtfrydrychewicz@…<p>
There is a subtle error in <a class="ext-link" href="https://docs.djangoproject.com/en/1.3/ref/contrib/contenttypes/#django.contrib.contenttypes.models.ContentType.get_object_for_this_type"><span class="icon">​</span>ContentType.get_object_for_this_type</a> method.
</p>
<pre class="wiki">def get_object_for_this_type(self, **kwargs):
return self.model_class()._default_manager.using(self._state.db).get(**kwargs)
</pre><p>
Database used to <em>get</em> <em>model_class</em> object is taken from self._state.db, which provides an error when <em>contenttype</em> model is hold in one database and model, of which object we're going to create, in another one.
</p>
<p>
Database should be provided using self.model_class().objects.db not self._state.db.
</p>
Resultshttps://code.djangoproject.com/ticket/16281#changeloghttps://code.djangoproject.com/ticket/17232
https://code.djangoproject.com/ticket/17232#17232: Multitable multi-inheritance: Deadly Diamond of DeathTue, 15 Nov 2011 01:34:00 GMTrich.harkins@…<p>
I ask you to consider the following found in 1.3.1 ("1.3.1" wasn't in the Version dropdown at time of submission, BTW):
</p>
<pre class="wiki"> from django.db import models
import uuid
# Create your models here.
class Tag(models.Model):
tag_name = models.CharField(max_length=32)
uuid = models.CharField(max_length=36, unique=True, default=uuid.uuid4)
class IdentifiableTag(Tag):
html_id = models.CharField(max_length=64, null=True)
class LinkableTag(Tag):
url = models.URLField(verify_exists=False, null=True)
class AnchorTag(IdentifiableTag, LinkableTag):
name = models.CharField(max_length=32, null=True)
def save(self, **_kw):
self.tag_name = 'a'
super(AnchorTag, self).save(**_kw)
</pre><p>
In essence, an Anchor is a linkable, identifiable tag. Let's not get too worked up about the semantics (yes, all tags could have an id attribute) -- I just needed a sanitary illustration.
</p>
<p>
The following test case will work:
</p>
<pre class="wiki"> from django.test import TestCase
from models import *
class DDDTests(TestCase):
def test_base_tag(self):
tag_uuid = uuid.uuid4()
tag = Tag(tag_name='something', uuid=tag_uuid)
self.assertEqual(tag.uuid, tag_uuid)
self.assertEqual(tag.tag_name, 'something')
def test_id_tag(self):
tag_uuid = uuid.uuid4()
tag = IdentifiableTag(tag_name='something',
uuid=tag_uuid,
html_id='blah')
self.assertEqual(tag.uuid, tag_uuid)
self.assertEqual(tag.tag_name, 'something')
self.assertEqual(tag.html_id, 'blah')
def test_link_tag(self):
tag_uuid = uuid.uuid4()
tag = LinkableTag(tag_name='something',
uuid=tag_uuid,
url='http://blah.com/')
self.assertEqual(tag.uuid, tag_uuid)
self.assertEqual(tag.tag_name, 'something')
self.assertEqual(tag.url, 'http://blah.com/')
</pre><p>
Everything is hunky-dory. No worries here, everything as you'd expect. Now let's look at the following extra test method:
</p>
<pre class="wiki"> def test_anchor_tag(self):
tag_uuid = uuid.uuid4()
tag = AnchorTag(name='hello',
uuid=tag_uuid,
html_id='world',
url='http://blah.com/')
self.assertEqual(tag.uuid, tag_uuid)
self.assertEqual(tag.name, 'a')
self.assertEqual(tag.html_id, 'world')
self.assertEqual(tag.url, 'http://blah.com/')
</pre><p>
If you think this should pass, I'd agree with you. However, if run:
</p>
<pre class="wiki"> Creating test database for alias 'default'...
F...
======================================================================
FAIL: test_anchor_tag (ddd.tests.DDDTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/tmp/show_ddd/ddd/tests.py", line 42, in test_anchor_tag
self.assertEqual(tag.uuid, tag_uuid)
AssertionError: UUID('fff54d5b-ee37-48d8-a091-dc4aaf88770a') != UUID('beff99f9-f9b7-4768-b8b2-259f9b0922c5')
----------------------------------------------------------------------
Ran 4 tests in 0.001s
FAILED (failures=1)
</pre><p>
So why is this? Well, I traced the Django code and found something peculiar with the _meta.fields of AnchorTag:
</p>
<pre class="wiki"> In [1]: from ddd.models import *
In [2]: [field.name for field in Tag._meta.fields]
Out[2]: ['id', 'tag_name', 'uuid']
In [3]: [field.name for field in IdentifiableTag._meta.fields]
Out[3]: ['id', 'tag_name', 'uuid', 'tag_ptr', 'html_id']
In [4]: [field.name for field in LinkableTag._meta.fields]
Out[4]: ['id', 'tag_name', 'uuid', 'tag_ptr', 'url']
In [5]: [field.name for field in AnchorTag._meta.fields]
Out[5]:
['id',
'tag_name',
'uuid',
'tag_ptr',
'html_id',
'id',
'tag_name',
'uuid',
'tag_ptr',
'url',
'linkabletag_ptr',
'identifiabletag_ptr',
'name']
</pre><p>
The issue seems to be that 'uuid', 'id', and 'tag_name' are represented twice due to the shared inheritance path. This causes Model.<span class="underline">init</span> to process uuid twice (popping it off the kwargs the first time and thinking it should use the default the second, triggering a new uuid.uuid4() call). This stems from the logic in Options._fill_fields_cache() not checking for duplicate fields from the parents. My feeble attempt at a correction is:
</p>
<pre class="wiki"> def _fill_fields_cache(self):
cache = []
for parent in self.parents:
for field, model in parent._meta.get_fields_with_model():
if model:
cache.append((field, model))
else:
cache.append((field, parent))
cache.extend([(f, None) for f in self.local_fields])
self._field_cache = tuple(cache)
# My feeble attempt
name_cache = []
for field, _ in cache:
if field not in name_cache:
name_cache.append(field)
self._field_name_cache = name_cache
# Old line
#self._field_name_cache = [x for x, _ in cache]
</pre><p>
This seems to work and passes all the unit tests above. However, I could just be "Doing it wrong" (TM), so I would also appreciate advice in finding another alternative if that is the case.
</p>
Resultshttps://code.djangoproject.com/ticket/17232#changeloghttps://code.djangoproject.com/ticket/17726
https://code.djangoproject.com/ticket/17726#17726: Admin's Recent Actions broken for multiple admin site instances with unique registered modelsSun, 19 Feb 2012 18:52:50 GMTsmacleod<p>
The Recent Actions list contains actions carried out from all admin site instances a user has access to. This causes problems when there exists a model which is not registered in all instances, and a User with access to multiple instances. If an action is carried out on this model it will appear in the recent list of all admin sites. If the model is not registered to an instance, the link generated will be invalid.
</p>
<p>
Ex:
</p>
<ul><li>AdminSite1 has model Model1 registered
</li><li>AdminSite2 does not have Model1 registered
</li><li>User has access to both admin sites
</li><li>User adds a Model1 in AdminSite1 (Action1)
</li><li>User visits AdminSite2, and clicks the Action1 link
</li><li>User is directed to an invalid URL (url for Model1 in AdminSite2)
</li></ul>Resultshttps://code.djangoproject.com/ticket/17726#changeloghttps://code.djangoproject.com/ticket/17943
https://code.djangoproject.com/ticket/17943#17943: Too many open file descriptors while using memcacheTue, 20 Mar 2012 21:34:27 GMTm.gajda@…<p>
Hi all,
</p>
<p>
I am using Django 1.3.1 with memcached server under Linux (PLD distro). Django application is run with runfcgi command (maxspare set to 20). After switching to Django 1.3.1 (from line 1.2.x) I encountered very strange behaviour -- the app became crashing after some time.
</p>
<p>
What I have discovered is very large number of open socket connections made by the Django app to the memcached server (lsof show hundrets of open descriptors). After some time the app process had been killed by the system, due to exceeded number of opened file descriptors.
</p>
<p>
Look at Google pointed me to the ticket <a class="closed ticket" href="https://code.djangoproject.com/ticket/15324" title="memcached cache backend creating new connection for every action (closed: fixed)">#15324</a>. Since that patch has been incorporated in the Django 1.3.1, I have started digging into memcached Django wrapper over the pyton-memcached module (django.core.cache.backends.memcached). What I found is that Django app run in multithreaded mode creates new cache object for every thread. This is probably good information, since it has allowed avoid difficult race conditions. What is sad - after closing/releasing the thread, the cache object is somehow not deleted properly. I mean it seems that it does not clean up all gathered resources properly. This lasts with large number of opened file descriptors in the memcached case.
</p>
<p>
I have added simple patch fixing said behaviour. It works quite well for me, thus I assume I could be considered to be improved and somehow merged with the Django sources. I have not created any tests, I am sorry for that.
</p>
Resultshttps://code.djangoproject.com/ticket/17943#changeloghttps://code.djangoproject.com/ticket/17955
https://code.djangoproject.com/ticket/17955#17955: Uploading a file without using django formsFri, 23 Mar 2012 02:05:11 GMTalexandre@…<p>
Hi,
</p>
<p>
i was trying to upload a file to my django backend without using django forms, but i was not able to it : my file was constantly getting dropped by the multiparser!
</p>
<p>
my multipart/formdata post request has two standard string post values :
</p>
<p>
Content-Disposition: form-data; name="foo" \r\n\r\n
</p>
<p>
and one file :
Content-Disposition: form-data; filename="bar"\r\n
Content-Type: image/png\r\n\r\n
</p>
<p>
I made it work simply by changing the multipartparser.py file this way :
</p>
<p>
Current :
</p>
<pre class="wiki">
92 def parse(self):
...
141 try:
142 disposition = meta_data['content-disposition'][1]
143 field_name = disposition['name'].strip()
144 except (KeyError, IndexError, AttributeError):
145 continue
</pre><p>
New :
</p>
<pre class="wiki"> def parse(self):
...
field_name = ''
try:
disposition = meta_data['content-disposition'][1]
if disposition.has_key('name'):
field_name = disposition['name'].strip()
else:
field_name = disposition['filename'].strip()
except (KeyError, IndexError, AttributeError):
continue
</pre><p>
I think the change is pretty straightforward, and would be really nice!
</p>
Resultshttps://code.djangoproject.com/ticket/17955#changeloghttps://code.djangoproject.com/ticket/19567
https://code.djangoproject.com/ticket/19567#19567: Make javascript i18n view as CBV and more extensible.Sat, 05 Jan 2013 10:01:04 GMTniwi<p>
The current view populates a global namespace (see <a href="https://code.djangoproject.com/ticket/18231">https://code.djangoproject.com/ticket/18231</a>) but also is very monolitic.
</p>
<p>
My proposal is create a CBV. I don't understand the use of templates for rendering a view (related ticket).
Now, the initial code is available on this file: <a class="ext-link" href="https://github.com/niwibe/django-jsgettext/blob/master/djsgettext/views.py"><span class="icon">​</span>https://github.com/niwibe/django-jsgettext/blob/master/djsgettext/views.py</a>
</p>
<p>
If the proposal is accepted, I will create a patch.
</p>
Resultshttps://code.djangoproject.com/ticket/19567#changeloghttps://code.djangoproject.com/ticket/21554
https://code.djangoproject.com/ticket/21554#21554: incorrect SQL generated when using multiple inheritanceTue, 03 Dec 2013 21:29:28 GMTpegler<p>
Our application makes use of multiple-inheritance and we've just come across an interesting bug. There is a test case attached and it fails against the latest 1.4, 1.5, 1.6, and master versions. Though the reason changes between versions 1.5 and 1.6.
</p>
<p>
The models:
</p>
<pre class="wiki">class Person(models.Model):
name = models.CharField(max_length=50)
class Politician(models.Model):
politician_id = models.AutoField(primary_key=True)
title = models.CharField(max_length=50)
class Congressman(Person, Politician):
state = models.CharField(max_length=2)
class Senator(Congressman):
pass
</pre><p>
The statement <tt> Senator.objects.get(politician_id=1) </tt> produces incorrect SQL for all versions, but is different between versions.
</p>
<p>
1.4.10 and 1.5.5 result in the error "<a class="wiki" href="https://code.djangoproject.com/wiki/DoesNotExist">DoesNotExist</a>: Senator matching query does not exist." due to it trying to join demo_politician onto demo_senator via demo_senator.congressman_ptr_id instead of demo_politician.politician_id
</p>
<pre class="wiki">SELECT "demo_person"."id", "demo_person"."name", T5."politician_id", T5."title", "demo_congressman"."politician_ptr_id", "demo_congressman"."person_ptr_id", "demo_congressman"."state", "demo_senator"."congressman_ptr_id"
FROM "demo_senator"
INNER JOIN "demo_congressman" ON ("demo_senator"."congressman_ptr_id" = "demo_congressman"."person_ptr_id")
INNER JOIN "demo_person" ON ("demo_senator"."congressman_ptr_id" = "demo_person"."id")
INNER JOIN "demo_politician" T5 ON ("demo_senator"."congressman_ptr_id" = T5."politician_id")
WHERE "demo_congressman"."politician_ptr_id" = 1
</pre><p>
1.6 and master results in the error "OperationalError: no such column: demo_congressman.politician_id". It incorrectly thinks that politician_id is on demo_congressman instead of demo_politician.
</p>
<pre class="wiki">SELECT "demo_person"."id", "demo_person"."name", "demo_congressman"."politician_id", "demo_congressman"."title", "demo_congressman"."politician_ptr_id", "demo_congressman"."person_ptr_id", "demo_congressman"."state", "demo_senator"."congressman_ptr_id"
FROM "demo_senator"
INNER JOIN "demo_congressman" ON ( "demo_senator"."congressman_ptr_id" = "demo_congressman"."person_ptr_id" )
INNER JOIN "demo_person" ON ( "demo_congressman"."person_ptr_id" = "demo_person"."id" )
WHERE "demo_congressman"."politician_ptr_id" = 1
</pre>Resultshttps://code.djangoproject.com/ticket/21554#changeloghttps://code.djangoproject.com/ticket/23051
https://code.djangoproject.com/ticket/23051#23051: QuerySet.only() fail to work with reverse o2o relationshipsThu, 17 Jul 2014 10:12:10 GMTvvd<p>
Specifying a field from reverse relationship model in the .only() queryset method have no effect on compiled query:
</p>
<pre class="wiki"># sample models
class Person(models.Model):
name = models.CharField(max_length=64)
class PersonExtra(models.Model):
bio = models.TextField()
information = models.TextField()
person = models.OneToOneField(Person)
# manage.py shell
&gt;&gt;&gt; from testapp.models import Person
&gt;&gt;&gt; print Person.objects.all().only('name').query
SELECT "testapp_person"."id", "testapp_person"."name" FROM "testapp_person"
&gt;&gt;&gt; print Person.objects.all().select_related('personextra').only('name', 'personextra__bio').query # expected table join and personextra__bio to be loaded
SELECT "testapp_person"."id", "testapp_person"."name" FROM "testapp_person"
</pre><p>
defer() method works fine:
</p>
<pre class="wiki">&gt;&gt;&gt; print Person.objects.all().select_related('personextra').defer('personextra__information').query
SELECT "testapp_person"."id", "testapp_person"."name", "testapp_personextra"."id", "testapp_personextra"."bio", "testapp_personextra"."person_id" FROM "testapp_person" LEFT OUTER JOIN "testapp_personextra" ON ( "testapp_person"."id" = "testapp_personextra"."person_id" )
</pre>Resultshttps://code.djangoproject.com/ticket/23051#changeloghttps://code.djangoproject.com/ticket/24125
https://code.djangoproject.com/ticket/24125#24125: TemplateDetailView in admindocs requires a single Django templates engineSun, 11 Jan 2015 18:11:10 GMTaaugustin<p>
<tt>TemplateDetailView.get_context_data()</tt> calls <tt>Engine.get_default()</tt> which raises <tt>ImproperlyConfigured</tt> if zero or several Django templates engines are configured.
</p>
<p>
This limitation should either be lifted or documented. Gracefully showing an error message would already be better than failing with an uncaught exception.
</p>
Resultshttps://code.djangoproject.com/ticket/24125#changeloghttps://code.djangoproject.com/ticket/24167
https://code.djangoproject.com/ticket/24167#24167: Backend-agnostic template internationalizationSat, 17 Jan 2015 08:22:40 GMTaaugustin<p>
Currently <tt>makemessages</tt> calls <tt>django.utils.translation.templatize</tt> to turn Django templates into something gettext understands. There is no way for alternate template engines to hook into the string extraction machinery.
</p>
<p>
This supersedes <a class="closed ticket" href="https://code.djangoproject.com/ticket/20811" title="New feature: Makemessages currently does not support alternative template languages (closed: wontfix)">#20811</a> and <a class="closed ticket" href="https://code.djangoproject.com/ticket/23299" title="New feature: Add some interoperability to _() function calls parsing in templatize ... (closed: wontfix)">#23299</a>.
</p>
Resultshttps://code.djangoproject.com/ticket/24167#changeloghttps://code.djangoproject.com/ticket/24179
https://code.djangoproject.com/ticket/24179#24179: FilteredSelectMultiple widget - add filter field to the right column.Mon, 19 Jan 2015 12:58:56 GMTgdmka<p>
I found that working with large datasets using <em>filter_horizontal</em> and thus FilteredSelectMultiple widget can be painful if you need to filter out selected entries.
</p>
<blockquote>
<p>
As, the UI is builded dynamically it is pretty easy to achieve the result you see below. I believe this feature is small but important.
</p>
</blockquote>
<p>
<a style="padding:0; border:none" href="http://i.imgur.com/E2qGjLf.png"><img src="http://i.imgur.com/E2qGjLf.png" alt="http://i.imgur.com/E2qGjLf.png" title="http://i.imgur.com/E2qGjLf.png" /></a>
</p>
<p>
I have a patch for that, should i attach it to the ticket or i can simply make a Pull request on Github referring this particular ticket?
</p>
Resultshttps://code.djangoproject.com/ticket/24179#changelog