Django: Ticket Queryhttps://code.djangoproject.com/query?status=!closed&keywords=~orm&order=status
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=~orm&order=status
Trac 1.0.7https://code.djangoproject.com/ticket/10403
https://code.djangoproject.com/ticket/10403#10403: provide declarative syntax to define FormSets - including ModelFormSet and InlineFormSetTue, 03 Mar 2009 18:21:58 GMTKoen Biermans <koen.biermans@…><p>
Provide a declarative mechanism to define modelformsets or inlineformsets.
</p>
<p>
The attached patch allows definitions like this:
</p>
<pre class="wiki">class AuthorForm(forms.ModelForm):
class Meta:
model = Author
class DeclarativeAuthorFormSet(forms.models.ModelFormSet):
form = AuthorForm
model = Author
extra = 3
</pre><p>
and
</p>
<pre class="wiki">class BookForm(forms.ModelForm):
class Meta:
model = Book
class DeclarativeAuthorBooksFormSet(forms.models.InlineFormSet):
model = Book
form = BookForm
parent = 'author'
</pre><p>
An advantage is that the defined form is directly used as the form class in the formset, not as a base class for a new form class (what inlineformset_factory does). This way specific field definitions and other customisations in the form work like they should so you don't need to redefine things in <span class="underline">init</span>().
</p>
Resultshttps://code.djangoproject.com/ticket/10403#changeloghttps://code.djangoproject.com/ticket/14217
https://code.djangoproject.com/ticket/14217#14217: Fieldname cannot be the same as the Modelname when using model inheritanceThu, 02 Sep 2010 09:49:33 GMTwillian<pre class="wiki">class Place(models.Model):
pass
class Restaurant(Place):
restaurant = models.CharField(max_length=100)
</pre><p>
When accessing Restaurant in the admin, a ValueError is Raised:
</p>
<hr />
<p>
ValueError at /admin/questionnaire/restaurant/add/
Cannot assign "<em>": "Restaurant.restaurant" must be a "Restaurant" instance.
---
</em></p>
Resultshttps://code.djangoproject.com/ticket/14217#changeloghttps://code.djangoproject.com/ticket/14317
https://code.djangoproject.com/ticket/14317#14317: numberformat.format produces wrong resultsMon, 20 Sep 2010 19:45:13 GMTakaariai<p>
The problem:
</p>
<pre class="wiki">&gt;&gt;&gt; from django.utils.numberformat import format
&gt;&gt;&gt; print format(0.000000001, ',', 2)
1e-10,2
</pre><p>
It can be fixed with using '%.2f' % number (the format string can be constructed dynamically), and then replacing the decimal separator and doing the grouping if needed. As a bonus, it is faster that way.
</p>
Resultshttps://code.djangoproject.com/ticket/14317#changeloghttps://code.djangoproject.com/ticket/15667
https://code.djangoproject.com/ticket/15667#15667: Implement template-based widget renderingWed, 23 Mar 2011 12:37:45 GMTbrutasse<p>
Following <a class="ext-link" href="https://groups.google.com/d/topic/django-developers/fMQnk2fAo_A/discussion"><span class="icon">​</span>this proposal on django-dev</a>, this ticket tracks the status of replacing the widgets rendering code with a template-based system.
</p>
<p>
The proposal is based on an existing implementation, <a class="ext-link" href="https://github.com/brutasse/django-floppyforms"><span class="icon">​</span>django-floppyforms</a>. The api provides several ways of extending a widget:
</p>
<ul><li>Widget.template_name: the name of the template used to render the widget
</li><li>Widget.get_context_data(): a way to inject additional context data
</li><li>Widget.get_context(name, value, attrs=None): this method calls get_context_data() and provides the basic context variables: attrs, hidden, name, required, type.
</li></ul><p>
I'm actively working on a patch and will attach it to the ticket as soon as I can so that the implementation and extension points can be discussed.
</p>
Resultshttps://code.djangoproject.com/ticket/15667#changeloghttps://code.djangoproject.com/ticket/16922
https://code.djangoproject.com/ticket/16922#16922: Add a template-based form rendering systemFri, 23 Sep 2011 19:28:50 GMTcarljm<p>
This was accepted as a GSoC project for 2011, and the work was done by Gregor Müllegger. There were <a class="ext-link" href="http://groups.google.com/group/django-developers/browse_frm/thread/3791152616fd95ae/6bbb2bf4d2f6752c?lnk=gst&amp;q=form+rendering+api#6bbb2bf4d2f6752c"><span class="icon">​</span>extensive discussions</a> on the django-developers mailing list about the API.
</p>
<p>
This ticket is to track the remaining work to get this template-based form rendering API into trunk. The most recent code is at <a class="ext-link" href="https://github.com/carljm/django/compare/master...soc2011%2Fform-rendering"><span class="icon">​</span>https://github.com/carljm/django/compare/master...soc2011%2Fform-rendering</a> - that branch also contains code for <a class="assigned ticket" href="https://code.djangoproject.com/ticket/15667" title="New feature: Implement template-based widget rendering (assigned)">#15667</a> and <a class="closed ticket" href="https://code.djangoproject.com/ticket/16921" title="New feature: Add assertHTMLEqual and related assert methods to TestCase (closed: fixed)">#16921</a>.
</p>
<p>
I expect that of those three tickets, <a class="closed ticket" href="https://code.djangoproject.com/ticket/16921" title="New feature: Add assertHTMLEqual and related assert methods to TestCase (closed: fixed)">#16921</a> can be merged first, then <a class="assigned ticket" href="https://code.djangoproject.com/ticket/15667" title="New feature: Implement template-based widget rendering (assigned)">#15667</a>, and this one last.
</p>
<p>
The primary issue that still needs to be resolved on this ticket, as well as <a class="assigned ticket" href="https://code.djangoproject.com/ticket/15667" title="New feature: Implement template-based widget rendering (assigned)">#15667</a>, is performance. <a class="ext-link" href="https://github.com/carljm/formrenderbench"><span class="icon">​</span>https://github.com/carljm/formrenderbench</a> can help with setting up benchmarks.
</p>
Resultshttps://code.djangoproject.com/ticket/16922#changeloghttps://code.djangoproject.com/ticket/18729
https://code.djangoproject.com/ticket/18729#18729: Admin changelist view defaults to `DISTINCT`, unusable on reasonably sized databasesTue, 07 Aug 2012 20:24:41 GMThcarvalhoalves<p>
The default behavior on the admin is not usable for reasonably sized tables (a couple thousand tuples is enough for &gt;1s queries).
</p>
<p>
Right now, it always includes a <tt>DISTINCT</tt> clause if you add a M2M field on <tt>list_filter</tt>, even if you're not applying any filters. Use of <tt>DISTINCT</tt> is known to be painfully slow, and even more so without a <tt>WHERE</tt> clause, because it forces SQL databases into a full table scan. The behavior is not easily overridden because the logic is scattered on a couple <tt>ChangeList</tt> methods (<a class="ext-link" href="https://github.com/django/django/blob/master/django/contrib/admin/views/main.py#L299"><span class="icon">​</span>https://github.com/django/django/blob/master/django/contrib/admin/views/main.py#L299</a>).
</p>
<p>
The only solution right now is not including a M2M field on <tt>list_filter</tt> and limiting functionality. It would be better if that behavior could be overridden (a <tt>use_distinct</tt> parameter on <tt>get_query_set</tt>?) or, optimally, moving this logic somewhere else. Ticket <a class="new ticket" href="https://code.djangoproject.com/ticket/15819" title="Bug: Admin searches should use distinct, if query involves joins (new)">#15819</a> already includes a patch for that.
</p>
Resultshttps://code.djangoproject.com/ticket/18729#changeloghttps://code.djangoproject.com/ticket/22229
https://code.djangoproject.com/ticket/22229#22229: Invalid data can cause InlineFormSet.is_valid to throw ValueErrorFri, 07 Mar 2014 17:22:27 GMTanonymous<p>
The InlineFormSet's foreign key field ("&lt;input name='myformset-0-id' ...&gt;") seems to assume that its data is valid for all of the initial data. Thus, if it is altered, the database layer will fail to convert it and throw an exception, instead of reporting that the form is invalid. For an integer foreign key, this takes form of a ValueError thrown by the int function.
</p>
<p>
I've created a test demonstrating the issue here: <a class="ext-link" href="https://gist.github.com/ColonelThirtyTwo/edbc575b10b068397dc7"><span class="icon">​</span>https://gist.github.com/ColonelThirtyTwo/edbc575b10b068397dc7</a>
</p>
Resultshttps://code.djangoproject.com/ticket/22229#changeloghttps://code.djangoproject.com/ticket/22268
https://code.djangoproject.com/ticket/22268#22268: values_list() on a ManyToManyField returns extra None's when iterated over.Thu, 13 Mar 2014 11:18:28 GMTk_sze<p>
Suppose you have a <tt>schools</tt> app, with these model definitions:
</p>
<pre class="wiki">from django.db import models
class School(models.Model):
name = models.CharField(unique=True, max_length=255)
class Class(models.Model):
school = models.ForeignKey(School)
name = models.CharField(unique=True, max_length=255)
students = models.ManyToManyField('Student')
class Student(models.Model):
surname = models.CharField(max_length=255)
given_name = models.CharField(max_length=255)
</pre><p>
Now, try this in the Django shell:
</p>
<pre class="wiki">$ python manage.py shell
&gt;&gt;&gt; from schools.models import School, Class, Student
# Create the school
&gt;&gt;&gt; concordia = School(name='Concordia University')
&gt;&gt;&gt; concordia.save()
# Create the Software Engineering class
&gt;&gt;&gt; soen = Class(school=concordia, name='Software Engineering')
&gt;&gt;&gt; soen.save()
# Create the Computer Engineering class
&gt;&gt;&gt; coen = Class(school=concordia, name='Computer Engineering')
&gt;&gt;&gt; coen.save()
# Create a student
&gt;&gt;&gt; john_smith = Student(surname='Smith', given_name='John')
&gt;&gt;&gt; john_smith.save()
# Add this student into one of the classes
&gt;&gt;&gt; soen.students.add(john_smith)
# Now make a query using values_list
&gt;&gt;&gt; students = Class.objects.values_list('students', flat=True)
# How many students are there supposed to be in this `students` QuerySet?
&gt;&gt;&gt; print students.count()
1
# What if we iterate over it?
&gt;&gt;&gt; for s in students:
&gt;&gt;&gt; print s
1
None
# Wait, what!?
&gt;&gt;&gt; print len(list(students))
&gt;&gt;&gt; 2
</pre>Resultshttps://code.djangoproject.com/ticket/22268#changeloghttps://code.djangoproject.com/ticket/23448
https://code.djangoproject.com/ticket/23448#23448: Update ISO_INPUT_FORMATS to allow date filtering for ISO8601 datesMon, 08 Sep 2014 04:30:18 GMTjaegerpicker<p>
Currently django_filters and django_rest_framework pull in the ISO_INPUT_FORMATS dictionary from django.utils.formats to try and convert dates/datetimes passed in as strings to datetime objects. There is currently no format strings compatible with datetime.isoformat(). I have updated the dictionary to add compatible format strings and tested django_filters and django_rest_framework, both work correctly with this update. I've ran all of the tests in django and all pass as expected. This is the github pull request: <a class="ext-link" href="https://github.com/django/django/pull/3195"><span class="icon">​</span>https://github.com/django/django/pull/3195</a>
</p>
Resultshttps://code.djangoproject.com/ticket/23448#changeloghttps://code.djangoproject.com/ticket/24782
https://code.djangoproject.com/ticket/24782#24782: Add TestCase.assertFormValidMon, 11 May 2015 14:45:36 GMTmjtamlyn<p>
In the case the form is actually valid, then <tt>assertFormValid(form)</tt> is no different to <tt>assertTrue(form.is_valid)</tt>, however when the assertion fails it should print some helpful output about which fields have validation errors and what those errors are. Even just outputting <tt>errors.as_json</tt> would help a lot. I've implemented code along the lines of this many times.
</p>
Resultshttps://code.djangoproject.com/ticket/24782#changeloghttps://code.djangoproject.com/ticket/24986
https://code.djangoproject.com/ticket/24986#24986: Selecting distinct on lower() function throws AttributeError("'Func' object has no attribute 'column'")Mon, 15 Jun 2015 16:32:15 GMTwbar<p>
I have simple table:
</p>
<pre class="wiki">class Author(models.Model):
name = models.CharField(max_length=40)
</pre><p>
I want to write Query using Django ORM to be similar to:
</p>
<pre class="wiki">SELECT DISTINCT LOWER(name) from my_app_author;
</pre><p>
I finally ended with:
</p>
<pre class="wiki">Author.objects.annotate(
name_lower=Func(F('name'), function='lower')
).distinct('name_lower')
</pre><p>
But I'm receiving error:
</p>
<pre class="wiki">Traceback (most recent call last):
File "/opt/venv/lib/python3.4/site-packages/django/db/models/query.py", line 138, in __repr__
data = list(self[:REPR_OUTPUT_SIZE + 1])
File "/opt/venv/lib/python3.4/site-packages/django/db/models/query.py", line 162, in __iter__
self._fetch_all()
File "/opt/venv/lib/python3.4/site-packages/django/db/models/query.py", line 965, in _fetch_all
self._result_cache = list(self.iterator())
File "/opt/venv/lib/python3.4/site-packages/django/db/models/query.py", line 238, in iterator
results = compiler.execute_sql()
File "/opt/venv/lib/python3.4/site-packages/django/db/models/sql/compiler.py", line 829, in execute_sql
sql, params = self.as_sql()
File "/opt/venv/lib/python3.4/site-packages/django/db/models/sql/compiler.py", line 381, in as_sql
distinct_fields = self.get_distinct()
File "/opt/venv/lib/python3.4/site-packages/django/db/models/sql/compiler.py", line 545, in get_distinct
result.append("%s.%s" % (qn(alias), qn2(target.column)))
AttributeError: 'Func' object has no attribute 'column'
</pre><p>
but when i write:
</p>
<pre class="wiki">Author.objects.annotate(
name_lower=Func(F('name'), function='lower')
).distinct('something')
</pre><p>
I'm receiving an error:
</p>
<pre class="wiki">django.core.exceptions.FieldError:
Cannot resolve keyword 'something' into field.
Choices are: id, name, name_lower, src_id
</pre><p>
As database driver I'm using <tt>'ENGINE': 'django.contrib.gis.db.backends.postgis'</tt>
</p>
Resultshttps://code.djangoproject.com/ticket/24986#changeloghttps://code.djangoproject.com/ticket/4848
https://code.djangoproject.com/ticket/4848#4848: Allow inline fields to be "mixed in" with the models' own fieldsWed, 11 Jul 2007 17:59:05 GMTleifbyron<p>
In newforms-admin, it would be quite helpful to be able to specify both a models' fields and its inline models' fields in the fields tuple of the options class. This would allow inline model fields to be "mixed in" with the models' own fields on the model's admin page. There are many situations where this would be preferable to the current situation -- always having inline model fields rendered below the models' own fields.
</p>
<p>
I suggested this feature in the Django-developers group, and Adrian suggested that I open a ticket.
</p>
<p>
<a class="ext-link" href="http://groups.google.com/group/django-developers/browse_thread/thread/c54d026eb46ad375/93bebf102281bb41#93bebf102281bb41"><span class="icon">​</span>http://groups.google.com/group/django-developers/browse_thread/thread/c54d026eb46ad375/93bebf102281bb41#93bebf102281bb41</a>
</p>
Resultshttps://code.djangoproject.com/ticket/4848#changeloghttps://code.djangoproject.com/ticket/5372
https://code.djangoproject.com/ticket/5372#5372: Cache inline ForeignKey optionsSun, 09 Sep 2007 21:36:10 GMTanonymousResultshttps://code.djangoproject.com/ticket/5372#changeloghttps://code.djangoproject.com/ticket/8165
https://code.djangoproject.com/ticket/8165#8165: When using can_order=True on formset, ordered_forms is not avaible when formset.is_valid() is falseFri, 08 Aug 2008 18:24:35 GMTJames Chua <james_027@…><p>
IMO ordered_forms attribute needs to be available even then the formset.is_valid() result to false in order to return the formset in order for re-inputting purpose
</p>
Resultshttps://code.djangoproject.com/ticket/8165#changeloghttps://code.djangoproject.com/ticket/8760
https://code.djangoproject.com/ticket/8760#8760: forms.ModelMultipleChoiceField should use "invalid_list" as error message keyMon, 01 Sep 2008 12:49:54 GMTdurdinator<p>
The MultipleChoiceField uses "invalid_list", but ModelMultipleChoiceField uses "list" as the key for the similar error message.
</p>
Resultshttps://code.djangoproject.com/ticket/8760#changeloghttps://code.djangoproject.com/ticket/10305
https://code.djangoproject.com/ticket/10305#10305: change the way ModelForms are instantiated in add_view, change_viewThu, 19 Feb 2009 19:55:56 GMTctao<p>
<tt>add_view</tt> and <tt>change_view</tt> have the following code:
</p>
<div class="code"><pre>ModelForm <span class="o">=</span> <span class="bp">self</span><span class="o">.</span>get_form<span class="p">(</span>request<span class="p">)</span>
<span class="o">...</span>
form <span class="o">=</span> ModelForm<span class="p">(</span>request<span class="o">.</span>POST<span class="p">,</span> request<span class="o">.</span>FILES<span class="p">)</span>
</pre></div><p>
or:
</p>
<div class="code"><pre> form <span class="o">=</span> ModelForm<span class="p">(</span>initial<span class="o">=</span>initial<span class="p">)</span>
</pre></div><p>
or:
</p>
<div class="code"><pre> form <span class="o">=</span> ModelForm<span class="p">(</span>request<span class="o">.</span>POST<span class="p">,</span> request<span class="o">.</span>FILES<span class="p">,</span> instance<span class="o">=</span>obj<span class="p">)</span>
</pre></div><p>
I would propose:
</p>
<div class="code"><pre><span class="k">if</span> <span class="nb">isinstance</span><span class="p">(</span>ModelForm<span class="p">,</span> ModelFormMetaclass<span class="p">):</span>
form <span class="o">=</span> ModelForm<span class="p">(</span>request<span class="o">.</span>POST<span class="p">,</span> request<span class="o">.</span>FILES<span class="p">)</span>
<span class="k">else</span>
form <span class="o">=</span> ModelForm
</pre></div><p>
This way gives the flexibility to override the function <tt>get_form(self, request, obj=None, **kwargs)</tt>, which could return a <tt>modelform_factory(self.model, **defaults)</tt> or an instance of a model form.
</p>
Resultshttps://code.djangoproject.com/ticket/10305#changeloghttps://code.djangoproject.com/ticket/10449
https://code.djangoproject.com/ticket/10449#10449: HTML accents not escaped out when using formsMon, 09 Mar 2009 15:44:36 GMTtipan<p>
When passing a translated string to a select box using a Forms Select widget, the output string still contains accent HTML entity codes.
</p>
<p>
For example: "Problemas para el Inicio de Sesi&amp;oacute;n o relacionados con la Cuenta
</p>
<p>
My code is set up as follows:
</p>
<p>
Models.py
</p>
<pre class="wiki">from django.utils import translation
from django.utils.translation import ugettext_lazy as _
SUBJECT = (
(10, _('Log-in or Account related problems')),
(20, _('General enquiry')),
(30, _('Other feedback')),
)
</pre><p>
This is then used in a form:
</p>
<pre class="wiki">class HelpFeedbackForm(forms.Form):
#form for user to submit their feedback when not logged in
subject = forms.CharField(widget=forms.Select(choices=SUBJECT))
</pre><p>
This is then presented in the template as:
{{ form.subject }}
</p>
<p>
which produces: "Problemas para el Inicio de Sesi&amp;oacute;n o relacionados con la Cuenta" as mentioned above.
</p>
<p>
The translations are returned from the django.po file, but all of the HTML entity codes are returned as is, in the Select box in the template.
Also, use of the safe template filter tag does affect this and the string is still rendered with accents.
</p>
Resultshttps://code.djangoproject.com/ticket/10449#changeloghttps://code.djangoproject.com/ticket/11097
https://code.djangoproject.com/ticket/11097#11097: Formset documentation should include a note about form.blah_ptr for derived modelsWed, 13 May 2009 14:57:12 GMTdrozzy<p>
Whenever a model inherits from a non-abstract model, it shares it's primary key with it.
As a consequence, the form produced by inlineformset_factory no longer has id field, by the "parentname_ptr" field.
</p>
<p>
For example imagine you have a case such as:
</p>
<pre class="wiki">class Car(models.Model):
color = #string field
class BMW(Car):
shop = models.ForeignKey(CarShop)
</pre><p>
Then in our view:
</p>
<pre class="wiki">car = BMW.objects.get(pk=1)
BMWFromset = inlineformset_factory(CarShop, BMW,
can_delete=True,
extra=1)
formset = BMWFormset(instance=car)
</pre><p>
The in our html:
</p>
<pre class="wiki">&lt;form method="post"&gt;
{{formset.management_form}}
&lt;ul&gt;
{% for form in formset.forms %}
&lt;li&gt;
&lt;!-- NOTICE that we do NOT use form.id here --&gt;
{{form.car_ptr}}
{{form}}
&lt;/li&gt;
{% endfor %}
&lt;/ul&gt;
&lt;input type="submit" value="submit" /&gt;
&lt;/form&gt;
</pre>Resultshttps://code.djangoproject.com/ticket/11097#changeloghttps://code.djangoproject.com/ticket/11313
https://code.djangoproject.com/ticket/11313#11313: list_editable fields don't support 'save' in multiuser environmentFri, 12 Jun 2009 20:05:30 GMTmargieroginski<p>
I don't think that the list_editable fields concept in the admin, as implmemented in 1.1, works. Imagine this:
</p>
<ol><li>User 1 brings up a changelist for an object and orders it by a 'deadline' field, most recent first, resulting in object 'foo' being shown as the most recent object
</li><li>User 2 edits object 'foo' and changes its deadline field so that it is no longer the most recent object
</li><li>User 1 still has the changelist form on his screen, and modifies the 'name' field of object foo. Then he hits 'save'.
</li></ol><p>
When the 'save' request from user 1 is processed, a queryset for the objects is created that is ordered by deadline. However, the ordering of the queryset in the POST request is different than the ordering of the queryset in the GET request made by user 1, due to the edit made by user 2. In the example I describe above, object foo is no longer the object that has the most recent deadline when the code processes user 1's POST request. Instead, object 'bar' is. In effect, it's as if the code thinks the user wants to change the name of object 'bar' instead of object 'foo'. However, the id sent with the post data is for object 'foo'. Eventually we get into _perform_unique_checks() and this sort of identifies that there is a problem. There is the following code:
</p>
<pre class="wiki">
# Exclude the current object from the query if we are editing an
# instance (as opposed to creating a new one)
if self.instance.pk is not None:
qs = qs.exclude(pk=self.instance.pk)
</pre><p>
In a non-multiuser case I think this would exclude the instance being edited, but in this case it doesn't. The result is that we drop into the next lines of code which generate an error, but the error looks like this: "Task with this None already exists." It contains the word "None" because the id field does not have a laberl attribute (ie self.fields<a class="missing wiki">id?</a>.label is None). I see this error when I print the form but it actually doesn't even show up in the admin ui. I just see the message "Please correct the errors below", but no errors are shown below.
</p>
<p>
In general it seems like a different tact needs to be taken for the POST request related to modification of editable fields. It seems to me that the code needs to identify the object being modified based on the id, and modify that object, rather than creating a queryset based on the filters and ordering and simply indexing in by form number.
</p>
<p>
Margie
</p>
Resultshttps://code.djangoproject.com/ticket/11313#changeloghttps://code.djangoproject.com/ticket/12157
https://code.djangoproject.com/ticket/12157#12157: FileSystemStorage does file I/O inefficiently, despite providing options to permit larger blocksizesWed, 04 Nov 2009 19:05:56 GMTalecmuffett<p>
FileSystemStorage contains the following:
</p>
<pre class="wiki"> def _open(self, name, mode='rb'):
return File(open(self.path(name), mode))
</pre><p>
..which is used to open files which are stored as FileFields in Django models.
</p>
<p>
If the programmer decides to hack through the file by using (for instance) the django.core.files.base.File.chunks() method:
</p>
<pre class="wiki"> def chunks(self, chunk_size=None):
"""
Read the file and yield chucks of ``chunk_size`` bytes (defaults to
``UploadedFile.DEFAULT_CHUNK_SIZE``).
"""
if not chunk_size:
chunk_size = self.__class__.DEFAULT_CHUNK_SIZE
if hasattr(self, 'seek'):
self.seek(0)
# Assume the pointer is at zero...
counter = self.size
while counter &gt; 0:
yield self.read(chunk_size)
counter -= chunk_size
</pre><p>
...the programmer would expect self.read() - which drops through to django.core.files.base.File.read() - to honour its arguments and for the I/O to occur in DEFAULT_CHUNK_SIZE blocks, currently 64k; however Dtrace shows otherwise:
</p>
<pre class="wiki">29830/0xaf465d0: open_nocancel("file.jpg\0", 0x0, 0x1B6) = 5 0
29830/0xaf465d0: fstat(0x5, 0xB007DB60, 0x1B6) = 0
29830/0xaf465d0: fstat64(0x5, 0xB007E1E4, 0x1B6) = 0 0
29830/0xaf465d0: lseek(0x5, 0x0, 0x1) = 0 0
29830/0xaf465d0: lseek(0x5, 0x0, 0x0) = 0 0
29830/0xaf465d0: stat("file.jpg\0", 0xB007DF7C, 0x0) = 0 0
29830/0xaf465d0: write_nocancel(0x1, "65536 113762\n\0", 0xD) = 13 0
29830/0xaf465d0: mmap(0x0, 0x11000, 0x3, 0x1002, 0x3000000, 0x0) = 0x7C5000 0
29830/0xaf465d0: read_nocancel(0x5, "\377\330\377\340\0", 0x1000) = 4096 0
29830/0xaf465d0: read_nocancel(0x5, "\333\035eS[\026+\360\215Q\361'I\304c`\352\v4M\272C\201\273\261\377\0", 0x1000) = 4096 0
...
...(many more 4kb reads elided)...
...
29830/0xaf465d0: sendto(0x4, 0x7C5014, 0x10000) = 65536 0
</pre><p>
...reading blocks in chunks of 4Kb (on OSX) and writing them in 64Kb blocks.
</p>
<p>
The reason this is occurring is because "open(self.path(name), mode)" is used to open the file, invoking the libc() stdio buffering which is much smaller than the 64kb requested by the programmer.
</p>
<p>
This can be kludged-around by hacking the open() statement:
</p>
<pre class="wiki"> def _open(self, name, mode='rb'):
return File(open(self.path(name), mode, 65536)) # use a larger buffer
</pre><p>
...or by not using the stdio file()/open() calls, instead using os.open()
</p>
<p>
In the meantime this means that Django is not handling FileSystemStorage reads efficiently.
</p>
<p>
It is not easy to determine whether this general stdio-buffer issue impacts other parts of Django's performance.
</p>
Resultshttps://code.djangoproject.com/ticket/12157#changeloghttps://code.djangoproject.com/ticket/12238
https://code.djangoproject.com/ticket/12238#12238: ModelAdmin ignores dynamic fields of ModelFormWed, 18 Nov 2009 03:19:05 GMTanonymous<p>
If a ModelForm is created and then modified to programatically add fields (say, in <tt>__init__</tt>), ModelAdmin ignores these fields when rendering the form. If one of these fields is added to the ModelForm's <tt>Meta</tt>, the field shows up just fine.
</p>
<p>
I would expect the field to display without the coaxing in <tt>Meta.fields</tt>.
</p>
<ol><li>Create a ModelForm
</li><li>Add it to ModelAdmin
</li><li>View Form
</li><li>Update ModelForm's <tt>__init__</tt> to include <tt>self.fields['xyz'] = forms.CharField(max_length=255, initial='keke')</tt>
</li><li>View Form (note no change)
</li><li>Update ModelForm's <tt>Meta.fields</tt> to include "xyz"
</li><li>View Form (note the change)
</li></ol>Resultshttps://code.djangoproject.com/ticket/12238#changeloghttps://code.djangoproject.com/ticket/13060
https://code.djangoproject.com/ticket/13060#13060: ManagementForm exception in case of bad prefix should be easier to understandMon, 08 Mar 2010 18:09:30 GMTKarel<p>
If user adds multiple formsets with prefixes, and specifies the prefix incorrectly when binding the form and validating:
</p>
<pre class="wiki">some_formset = SomeFormSet(request.POST, 'articles')
</pre><p>
instead of:
</p>
<pre class="wiki">some_formset = SomeFormSet(request.POST, prefix='articles')
</pre><p>
Django "suppresses" the original exception and raises only relatively unhelpful "ManagementForm data is missing or has been tampered with".
</p>
<p>
In file django/forms/formsets.py, line 57:
</p>
<pre class="wiki"> 54. if self.data or self.files:
55. form = ManagementForm(self.data, auto_id=self.auto_id, prefix=self.prefix)
56. if not form.is_valid():
57. raise ValidationError('ManagementForm data is missing or has been tampered with')
</pre><p>
Suggestion: include form._errors in output, because for such a small bug in code, it can take a really long time find it.
</p>
<pre class="wiki">{'INITIAL_FORMS': [u'This field is required.'],
'MAX_NUM_FORMS': [u'This field is required.'],
'TOTAL_FORMS': [u'This field is required.']}
</pre>Resultshttps://code.djangoproject.com/ticket/13060#changeloghttps://code.djangoproject.com/ticket/14009
https://code.djangoproject.com/ticket/14009#14009: custom formset validation documentation is incompleteMon, 26 Jul 2010 14:51:45 GMTsplatEric <mike@…><p>
The example for performing custom formset validation is incomplete. It does not take into account deleted forms, or empty forms for checking the unique titles constraint. It should read something along the lines of (changes highlighted by *&gt;):
</p>
<pre class="wiki">&gt;&gt;&gt; class BaseArticleFormSet(BaseFormSet):
... def clean(self):
... """Checks that no two articles have the same title."""
... if any(self.errors):
... # Don't bother validating the formset unless each form is valid on its own
... return
... titles = []
... for i in range(0, self.total_form_count()):
*&gt; if self.can_delete and self._should_delete_form(form):
*&gt; continue
... form = self.forms[i]
*&gt; if 'title' in form.cleaned_data:
... title = form.cleaned_data['title']
... if title in titles:
... raise forms.ValidationError, "Articles in a set must have distinct titles."
... titles.append(title)
</pre>Resultshttps://code.djangoproject.com/ticket/14009#changeloghttps://code.djangoproject.com/ticket/14096
https://code.djangoproject.com/ticket/14096#14096: Insert code generated by models using multiple inheritance is incorrect and fails in postgresqlWed, 11 Aug 2010 22:17:59 GMTpembo13<p>
When a model with multiple concrete parents is saved (inserted) the parents are saved first. Currently, the first parent is saved and its primary key is also set as the primary key of the yet unsaved top model. Any parent following uses the new primary key of 'self' and explicitly inserts the PK into the parent models table
</p>
<p>
There is no reason to explicitly set the PK of any of the parent classes, the code already handles retrieval of the DB assigned PK.
</p>
<p>
While other DBs let this pass, PostgreSQL does not. The problem comes not on the offending .save() but subsequent inserts to the table, this time <strong>without</strong> an explicit PK. The DB's internal counter has not advanced, so the next chosen PK already exists and yields a database error due to duplicate of a key field.
</p>
<p>
There is no apparent need to explicitly set any of the PK on insert. I believe that changing the following code block within source:django/trunk/django/db/models/base.py#13538 , line 533 , Model.save_base(...) can solve the problem:
</p>
<p>
from
</p>
<div class="code"><pre> <span class="k">if</span> update_pk<span class="p">:</span>
<span class="nb">setattr</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> meta<span class="o">.</span>pk<span class="o">.</span>attname<span class="p">,</span> result<span class="p">)</span>
</pre></div><p>
to
</p>
<div class="code"><pre> <span class="k">if</span> update_pk <span class="ow">and</span> cls <span class="o">==</span> <span class="bp">self</span><span class="o">.</span>__class__<span class="p">:</span>
<span class="nb">setattr</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> meta<span class="o">.</span>pk<span class="o">.</span>attname<span class="p">,</span> result<span class="p">)</span>
</pre></div><p>
I have attached a sample site ('minherit') with app ('data') and a test case in a ZIP file.
</p>
Resultshttps://code.djangoproject.com/ticket/14096#changeloghttps://code.djangoproject.com/ticket/14297
https://code.djangoproject.com/ticket/14297#14297: Accessing settings.FOO in hot spots cause performance problemsThu, 16 Sep 2010 16:56:38 GMTakaariai<p>
Trying to access settings.FOO (no matter if it exists or not) will cause performance problems if used in hot spots of code. The reason is that settings is actually LazyObject, and each access goes through <span class="underline">getattr</span>. The problem is well illustrated in ticket <a class="closed ticket" href="https://code.djangoproject.com/ticket/14290" title="Rendering is very inefficient when USE_L10N. Caching format values ... (closed: fixed)">#14290</a>, where performance is increased considerably if a setting is cached in a global attribute.
</p>
<p>
I am trying to fix this by refactoring LazySettings in the following way: Make the new LazySettings be a regular Python object, but with a special <span class="underline">getattr</span> method: When first accessed, it will set up the settings in the objects own <span class="underline">dict</span>. After this, each access to settings.FOO, where FOO exists, will not use <span class="underline">getattr</span>. When trying to access settings.BAR, where BAR does not exist, the access will still need to go through <span class="underline">getattr</span>. This should not be a performance problem, though.
</p>
<p>
The performance increase on my laptop (using the test from <a class="closed ticket" href="https://code.djangoproject.com/ticket/14290" title="Rendering is very inefficient when USE_L10N. Caching format values ... (closed: fixed)">#14290</a>, with USE_L10N = False) is from 1.1 to 0.8 seconds, or 0.3 seconds. This is the cost of accessing settings.USE_L10N 60000 times and settings.USE_I18N 10000 times, plus fifteen other accesses. (The test is the <a class="ext-link" href="http://localhost:8000/test/10000?timing"><span class="icon">​</span>http://localhost:8000/test/10000?timing</a> one).
</p>
<p>
Attached patch passes all tests (I know how to run).
</p>
Resultshttps://code.djangoproject.com/ticket/14297#changeloghttps://code.djangoproject.com/ticket/14688
https://code.djangoproject.com/ticket/14688#14688: BaseInlineFormSet does not support "auto_id"Mon, 15 Nov 2010 01:56:22 GMTvicvicvic<p>
<tt>BaseInlineFormSet.__init__</tt> does not accept the <tt>auto_id</tt> argument, unlike its ancestors. Furthmore, its parent <tt>BaseModelFormSet</tt> takes <tt>**kwargs</tt> and passes them along.
</p>
<p>
I can't think of a good reason for this omission/difference. I've attached a small patch to "match" <tt>BaseInlineFormSet.__init__</tt> with <tt>BaseModelFormSet.__init__</tt>. The patch puts the "new" <tt>auto_id</tt> argument last in order to maximize backwards compatibility (the order is different for <tt>BaseModelFormSet</tt>).
</p>
<p>
Arguably, both <tt>prefix</tt> and <tt>auto_id</tt> could be removed from the explicit arg list since they're just passed along (in both <tt>BaseModelFormSet</tt> and <tt>BaseInlineFormSet</tt>).
</p>
Resultshttps://code.djangoproject.com/ticket/14688#changeloghttps://code.djangoproject.com/ticket/14831
https://code.djangoproject.com/ticket/14831#14831: Django Template Style GuideSat, 04 Dec 2010 07:04:57 GMTDrMeers<p>
It would be nice to have a standard template style that should be followed. For example, I like to indent my Django templates by two additional spaces every time I enter a new HTML or template block. The Django core templates vary greatly in regards to style and indentation. Much of the time template readability is sacrificed in favour of attempting to preserve the "appearance" of the generated HTML code.
</p>
<p>
Regardless of what is decided, it would be great to have at least some guidelines for templates added to <a class="ext-link" href="http://docs.djangoproject.com/en/dev/internals/contributing/#coding-style"><span class="icon">​</span>http://docs.djangoproject.com/en/dev/internals/contributing/#coding-style</a>
</p>
Resultshttps://code.djangoproject.com/ticket/14831#changeloghttps://code.djangoproject.com/ticket/15015
https://code.djangoproject.com/ticket/15015#15015: Mixing read-only with ability to add new instances using a FormSetTue, 04 Jan 2011 19:44:02 GMTcoleifer<p>
A little background, I've been attempting to add permission-awareness to admin inlines using a technique like the one mentioned here:
<a class="ext-link" href="http://code.djangoproject.com/ticket/8060#comment:9"><span class="icon">​</span>http://code.djangoproject.com/ticket/8060#comment:9</a>
</p>
<p>
The problem occurs when I want to allow a user to be able to add new inline instances, but display the pre-existing ones as read-only. By overriding the get_readonly_fields() method in the event the user doesn't have change permissions, I'm able to make everything read-only...but this includes the formset's "extra_forms", or when the user clicks to add a new row.
</p>
<p>
Since read-only is an admin thing and is implemented in the formset-level as "exclude", it's going to be kind of tricky to tell, using just the FormSet API, which fields are actually excluded and which are just read-only. I would propose making readonly_fields an attribute of the form, just like exclude. Additionally, it makes sense to me for any 'extra_forms' on the FormSet to display all non-excluded fields as editable. Having a read-only field on a form that does not contain any data is odd.
</p>
Resultshttps://code.djangoproject.com/ticket/15015#changeloghttps://code.djangoproject.com/ticket/15574
https://code.djangoproject.com/ticket/15574#15574: IndexError: list index out of range caused by inline formsetsWed, 09 Mar 2011 08:57:45 GMTposwald<p>
Note: I originally reported this as ticket <a class="new ticket" href="https://code.djangoproject.com/ticket/14642" title="Bug: save_as=True and generic inline in admin gives IndexError (new)">#14642</a> but after discussion on the mailing list it has been decided that they are perhaps different issues. See <a class="ext-link" href="http://groups.google.com/group/django-developers/browse_thread/thread/8c66461f1712dbb9"><span class="icon">​</span>http://groups.google.com/group/django-developers/browse_thread/thread/8c66461f1712dbb9</a>
</p>
<p>
I was getting this error in my production system and I thought it was my forms. Turns out I could eliminate my forms as a source of the issue by using the admin. I've changed the summary to match. I reduced it down to this test case in Django 1.2.x:
</p>
<p>
models.py:
</p>
<pre class="wiki">class Thingy(models.Model):
description = models.CharField(max_length=256)
class ThingyItem(models.Model):
thingy = models.ForeignKey(Thingy)
description = models.CharField(max_length=256)
</pre><p>
admin.py:
</p>
<pre class="wiki">class ThingyItemInline(admin.TabularInline):
model = ThingyItem
extra = 0
class ThingyAdmin(admin.ModelAdmin):
inlines = [ThingyItemInline,]
admin.site.register(Thingy, ThingyAdmin)
admin.site.register(ThingyItem)
</pre><p>
Now do the following:
</p>
<ul><li>Create a new Thingy with several ThingyItems? in the admin and save it.
</li><li>Open the edit page.
</li><li>Open the edit page for the same thingy in a second browser window.
</li><li>Check the "Delete" button on the last ThingyItem? and save it in the second window.
</li><li>Now go back to the first form and save it
</li></ul><p>
When I do this, I get:
</p>
<pre class="wiki">Traceback (most recent call last):
File "/Users/poswald/Projects/django/tests/regressiontests/admin_inlines/tests.py", line 211, in test_concurrent_editing_views
response = self.client.post(reverse(edit_url, args=[self.thing.pk]), data[1])
File "/Users/poswald/Projects/django/django/test/client.py", line 455, in post
response = super(Client, self).post(path, data=data, content_type=content_type, **extra)
File "/Users/poswald/Projects/django/django/test/client.py", line 256, in post
return self.request(**r)
File "/Users/poswald/Projects/django/django/core/handlers/base.py", line 111, in get_response
response = callback(request, *callback_args, **callback_kwargs)
File "/Users/poswald/Projects/django/django/contrib/admin/options.py", line 308, in wrapper
return self.admin_site.admin_view(view)(*args, **kwargs)
File "/Users/poswald/Projects/django/django/utils/decorators.py", line 93, in _wrapped_view
response = view_func(request, *args, **kwargs)
File "/Users/poswald/Projects/django/django/views/decorators/cache.py", line 79, in _wrapped_view_func
response = view_func(request, *args, **kwargs)
File "/Users/poswald/Projects/django/django/contrib/admin/sites.py", line 190, in inner
return view(request, *args, **kwargs)
File "/Users/poswald/Projects/django/django/utils/decorators.py", line 28, in _wrapper
return bound_func(*args, **kwargs)
File "/Users/poswald/Projects/django/django/utils/decorators.py", line 93, in _wrapped_view
response = view_func(request, *args, **kwargs)
File "/Users/poswald/Projects/django/django/utils/decorators.py", line 24, in bound_func
return func(self, *args2, **kwargs2)
File "/Users/poswald/Projects/django/django/db/transaction.py", line 217, in inner
res = func(*args, **kwargs)
File "/Users/poswald/Projects/django/django/contrib/admin/options.py", line 978, in change_view
queryset=inline.queryset(request))
File "/Users/poswald/Projects/django/django/forms/models.py", line 680, in __init__
queryset=qs)
File "/Users/poswald/Projects/django/django/forms/models.py", line 416, in __init__
super(BaseModelFormSet, self).__init__(**defaults)
File "/Users/poswald/Projects/django/django/forms/formsets.py", line 47, in __init__
self._construct_forms()
File "/Users/poswald/Projects/django/django/forms/formsets.py", line 108, in _construct_forms
self.forms.append(self._construct_form(i))
File "/Users/poswald/Projects/django/django/forms/models.py", line 689, in _construct_form
form = super(BaseInlineFormSet, self)._construct_form(i, **kwargs)
File "/Users/poswald/Projects/django/django/forms/models.py", line 440, in _construct_form
kwargs['instance'] = self.get_queryset()[i]
File "/Users/poswald/Projects/django/django/db/models/query.py", line 173, in __getitem__
return self._result_cache[k]
IndexError: list index out of range
</pre><p>
It seems that the inline formset code is a bit brittle. An error is thrown when the data submitted in the management form is not in agreement with the state of the database. I'd like to make an automated test case for this but I'm not sure how to do that sequence of steps in the test client. If anyone can shed some light onto what the formset code is *supposed* to do in this situation it would be useful. I imagine the options are the second form overrides the first or something like a form validation error is raised that indicates the form is stale.
</p>
Resultshttps://code.djangoproject.com/ticket/15574#changeloghttps://code.djangoproject.com/ticket/16306
https://code.djangoproject.com/ticket/16306#16306: Form field documentation documents optional keyword arguments as field attributes.Mon, 20 Jun 2011 21:19:09 GMTShawnMilo<p>
I've tested this for forms.IntegerField and forms.DecimalField -- setting a max_value when the field is declared works normally, but if set in <span class="underline">init</span> (because it's unknown till runtime) no validators are assigned although the max_value value is properly set.
</p>
<pre class="wiki">
from django import forms
class TestForm(forms.Form):
amount = forms.IntegerField(max_value = 10)
class TestForm2(forms.Form):
amount = forms.IntegerField()
def __init__(self, *args, **kwargs):
super(TestForm2, self).__init__(*args, **kwargs)
self.fields['amount'].max_value = 10
x = TestForm({'amount': 12})
print x.is_valid() #returns False
print x.fields['amount'].max_value # returns 10
print x.fields['amount'].validators # [&lt;django.core.validators.MaxValueValidator object at 0x7febd5240610&gt;]
print x.errors #complains about size
x = TestForm2({'amount': 12})
print x.is_valid() #returns True
print x.fields['amount'].max_value #returns 10
print x.fields['amount'].validators # []
print x.errors #nothing
</pre><p>
Evidently this bug has existed for some time, because almost a year ago it was discussed on StackOverflow and the suggestion was to just completely replace the field at runtime:
</p>
<p>
<a class="ext-link" href="http://stackoverflow.com/questions/3470741/django-forms-integerfield-set-max-value-on-runtime"><span class="icon">​</span>http://stackoverflow.com/questions/3470741/django-forms-integerfield-set-max-value-on-runtime</a>
</p>
Resultshttps://code.djangoproject.com/ticket/16306#changeloghttps://code.djangoproject.com/ticket/17276
https://code.djangoproject.com/ticket/17276#17276: Slow anti-join query against PostgresMon, 21 Nov 2011 22:58:44 GMTdmitry@…<p>
For background on this ticket please see the following two discussions:
</p>
<ul><li><a class="ext-link" href="http://stackoverflow.com/questions/8190474/postgres-slow-outer-query-when-using-a-primary-key"><span class="icon">​</span>http://stackoverflow.com/questions/8190474/postgres-slow-outer-query-when-using-a-primary-key</a>
</li><li><a class="ext-link" href="https://groups.google.com/group/django-users/browse_thread/thread/7d13f2d8748b4f9f"><span class="icon">​</span>https://groups.google.com/group/django-users/browse_thread/thread/7d13f2d8748b4f9f</a>
</li></ul><p>
Basically, in a many-to-many mappings between models Student and Course, if I want to find all instances of Students that aren't registered for classes, I would issue the following Django query:
</p>
<pre class="wiki">Student.objects.filter(course__isnull=True)
</pre><p>
Django translates this into the following query:
</p>
<pre class="wiki">SELECT "student"."id", "student"."name"
FROM "student"
LEFT OUTER JOIN "course_students"
ON ("student"."id" = "course_students"."student_id")
LEFT OUTER JOIN "course"
ON ("course_students"."course_id" = "course"."id")
WHERE "course"."id" IS NULL
</pre><p>
The problem is that the way the WHERE clause is generated is very inefficient (at least when used with Postgres). Changing WHERE to "course_students"."student_id" IS NOT NULL yields orders of magnitude improved query plan. Here's the difference I'm seeing on real data:
</p>
<ul><li>Django way: (cost=1072479.36..6256437.79 rows=1 width=145)
</li><li>Hand-crafted: (cost=1518.71..1533.35 rows=1 width=145)
</li></ul><p>
I'm attaching a sample project with the model already set up. To see the generated SQL query, simply run "python manage.py anti-join."
</p>
Resultshttps://code.djangoproject.com/ticket/17276#changeloghttps://code.djangoproject.com/ticket/17577
https://code.djangoproject.com/ticket/17577#17577: Form instantiation hook for adminMon, 23 Jan 2012 02:34:13 GMTsimon29<p>
Currently there is no hook to alter how forms are instantiated in admin, without hacking add_view/change_view.
</p>
<p>
This simple change could allow some nice stuff like access to the request object for form validation, customising fields, etc.
</p>
<p>
<a class="ext-link" href="http://stackoverflow.com/a/2684552/489638"><span class="icon">​</span>http://stackoverflow.com/a/2684552/489638</a>
</p>
<p>
<a class="ext-link" href="http://stackoverflow.com/a/1388881/489638"><span class="icon">​</span>http://stackoverflow.com/a/1388881/489638</a>
</p>
<p>
Proposed syntax --
</p>
<pre class="wiki">class MyAdmin(admin.ModelAdmin):
...
def get_form_instance(self, request, obj=None):
... (default method calls get_form() here)
</pre><p>
</p>
Resultshttps://code.djangoproject.com/ticket/17577#changeloghttps://code.djangoproject.com/ticket/17637
https://code.djangoproject.com/ticket/17637#17637: Client side validation classes for formsSat, 04 Feb 2012 13:18:51 GMTkarthikabinav<p>
Having client side javascript validation for forms having common fields like username having only alphanumerics or password and Confirm password fields matching by providing a validation class.
</p>
<p>
For example a user should be able to do something like :
</p>
<pre class="wiki">forms.TextField(validators ="usernameValidation")
</pre><p>
And automatically a javascript validation for this form field should be in place.
</p>
<p>
One way to do it could be using HTML5 attributes like ticket <a class="closed ticket" href="https://code.djangoproject.com/ticket/16304" title="New feature: Add HTML5 'placeholder' attribute support to form fields. (closed: wontfix)">#16304</a>.
</p>
Resultshttps://code.djangoproject.com/ticket/17637#changeloghttps://code.djangoproject.com/ticket/18597
https://code.djangoproject.com/ticket/18597#18597: `BaseInlineFormSet` should attempt to get it's queryset from it's instance related manager before falling back to it's model's default managerMon, 09 Jul 2012 01:19:52 GMTcharettes<p>
The newly introduced <tt>prefetch_related</tt> method can be quite handy to avoid unnecessary queries (thanks Luke :), however it's quite useless when used with <tt>BaseInlineFormSet</tt> since <a class="ext-link" href="https://github.com/django/django/blob/4a103086d5c67fa4fcc53c106c9fdf644c742dd8/django/forms/models.py#L694"><span class="icon">​</span>it won't even try to get its needed `queryset` from the related manager</a>.
</p>
<p>
i.e.
</p>
<div class="code"><pre><span class="kn">from</span> <span class="nn">django.db</span> <span class="kn">import</span> models
<span class="k">class</span> <span class="nc">Author</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
name <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>max_length<span class="o">=</span><span class="mi">255</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">Book</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
name <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>max_length<span class="o">=</span><span class="mi">255</span><span class="p">)</span>
author <span class="o">=</span> models<span class="o">.</span>ForeignKey<span class="p">(</span>Author<span class="p">,</span> related_name<span class="o">=</span><span class="s">'books'</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
<span class="c"># Needed because `BaseModelFormSet.get_query_set` wants an ordered set or issue another query</span>
ordering <span class="o">=</span> <span class="p">(</span><span class="s">'pk'</span><span class="p">,)</span>
</pre></div><pre class="wiki">In [1]: from django.conf import settings
In [2]: from django.db import connection
In [3]: from library.models import *
In [4]: from django.forms.models import inlineformset_factory
In [5]: a = Author.objects.create(name='David Abram')
In [6]: b1 = Book.objects.create(name='Becoming Animal', author=a)
In [7]: b2 = Book.objects.create(name='The Spell of the Sensuous', author=a)
In [8]: BookInlineFormSet = inlineformset_factory(Author, Book)
In [9]: settings.DEBUG = True
In [10]: instance = Author.objects.prefetch_related('books').get()
In [11]: BookInlineFormSet(instance=instance)
Out[11]: &lt;django.forms.formsets.BookFormFormSet at 0x3c68d50&gt;
In [12]: print connection.queries
[{u'time': u'0.000', u'sql': u'SELECT "library_author"."id", "library_author"."name" FROM "library_author"'},
{u'time': u'0.000', u'sql': u'SELECT "library_book"."id", "library_book"."name", "library_book"."author_id" FROM "library_book" WHERE "library_book"."author_id" IN (1) ORDER BY "library_book"."id" ASC'},
{u'time': u'0.000', u'sql': u'SELECT "library_book"."id", "library_book"."name", "library_book"."author_id" FROM "library_book" WHERE "library_book"."author_id" = 1 ORDER BY "library_book"."id" ASC'}]
</pre><p>
I guess it's only a matter of time before people start trying to optimize their formsets (or their <tt>ModelAdmin</tt> by overriding <tt>get_queryset</tt>) and stumble on this <em>limitation</em>.
</p>
<p>
I've written a patch (I'll create a pull request) for which I'll write tests if this optimization is <em>Accepted</em>.
</p>
Resultshttps://code.djangoproject.com/ticket/18597#changeloghttps://code.djangoproject.com/ticket/19353
https://code.djangoproject.com/ticket/19353#19353: Make it easier to extend UserCreationForm for custom user modelsSat, 24 Nov 2012 10:32:08 GMTbmispelon<p>
The documentation <a class="ext-link" href="https://docs.djangoproject.com/en/dev/topics/auth/#custom-users-and-the-built-in-auth-forms"><span class="icon">​</span>states</a> that <tt>UserCreationForm</tt> must be re-written when using a custom user model.
</p>
<p>
However, for simple subclasses of <tt>AbstractUser</tt> it's actually simpler to extend (rather than rewrite) the existing form like so:
</p>
<div class="code"><pre><span class="k">class</span> <span class="nc">CustomUserCreationForm</span><span class="p">(</span>UserCreationForm<span class="p">):</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">(</span>UserCreationForm<span class="o">.</span>Meta<span class="p">):</span>
model <span class="o">=</span> CustomUser
</pre></div><p>
Unfortunately, this fails because the <tt>clean_username</tt> method of <tt>UserCreationForm</tt> still references the original <tt>User</tt> model directly (this technique works with <tt>UserChangeForm</tt> though).
To get it working, the original <tt>clean_username</tt> method needs to be copied over and modified to use the custom user model, like so:
</p>
<div class="code"><pre><span class="k">class</span> <span class="nc">CustomUserCreationForm</span><span class="p">(</span>UserCreationForm<span class="p">):</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">(</span>UserCreationForm<span class="o">.</span>Meta<span class="p">):</span>
model <span class="o">=</span> CustomUser
<span class="k">def</span> <span class="nf">clean_username</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
username <span class="o">=</span> <span class="bp">self</span><span class="o">.</span>cleaned_data<span class="p">[</span><span class="s">"username"</span><span class="p">]</span>
<span class="k">try</span><span class="p">:</span>
CustomUser<span class="o">.</span>objects<span class="o">.</span>get<span class="p">(</span>username<span class="o">=</span>username<span class="p">)</span>
<span class="k">except</span> CustomUser<span class="o">.</span>DoesNotExist<span class="p">:</span>
<span class="k">return</span> username
<span class="k">raise</span> forms<span class="o">.</span>ValidationError<span class="p">(</span><span class="bp">self</span><span class="o">.</span>error_messages<span class="p">[</span><span class="s">'duplicate_username'</span><span class="p">])</span>
</pre></div><p>
This works, but having to copy/paste some code is not a very good practice.
</p>
<p>
Therefore, I propose to change <tt>UserCreationForm.clean_username</tt> to use <tt>Meta.model</tt> instead of <tt>User</tt>.
</p>
<p>
This allows the creation of custom user creation forms by simply redefining the user model in the form's <tt>Meta</tt> class (like in the first example).
</p>
<p>
The documentation could also be extended to show an example of how to extend the builtin auth forms that require it.
</p>
Resultshttps://code.djangoproject.com/ticket/19353#changeloghttps://code.djangoproject.com/ticket/20023
https://code.djangoproject.com/ticket/20023#20023: Admin Inline form validation must go in Model.clean() if AdminInline.form is not specifiedMon, 11 Mar 2013 07:43:44 GMTchris.freeman.pdx@…<p>
The Django admin site page (./en/1.5/ref/contrib/admin) should mention something specific about inline form validation regarding where to put clean() code.
</p>
<p>
It seems that the only way I was able to clean a field changed as part of an admin inline form was in the Model.clean() method. I could not find a place where using clean_myfield() method worked as all for admin inline forms. Note the inline was not part of a formset, as it had a OneToOneField relationship to the main form.
</p>
<p>
This is not obvious in the documentation as the Model page mentions clean() and clean_field() but nothing about inlines. The documentation on Inlines mentions validation, but nothing on putting the code in the Model.clean(). Perhaps, also a warning that clean_field() is not run for admin inline form updates.
</p>
<p>
Please correct me if I'm mistaken about validation of inline forms within the Admin interface.
</p>
<p>
Regards, Chris
</p>
Resultshttps://code.djangoproject.com/ticket/20023#changeloghttps://code.djangoproject.com/ticket/20226
https://code.djangoproject.com/ticket/20226#20226: Django problematic when Oracle when column/table names are mixed caseTue, 09 Apr 2013 03:10:17 GMTcalcium<p>
In my Oracle DB, some of the tables have column names which are not uppercase only.
eg
column names are "FIRSTNAME", and "CallType".
</p>
<p>
When running a query against any table with such non-uppercase only columnnames, I get an error like
</p>
<p>
django.db.utils.DatabaseError: ORA-00904: "SOMETABLENAME"."CALLTYPE": invalid identifier.
</p>
<p>
I got around my problem by editing the compiler.py file.
/usr/local/lib/python2.7/dist-packages/django/db/models/sql/compiler.py
</p>
<p>
The diff is as follows.
</p>
<p>
<strong>* ~/Exploded/Django-1.5.1/django/db/models/sql/compiler.py 2013-03-29 07:07:20.000000000 +1100
--- /usr/local/lib/python2.7/dist-packages/django/db/models/sql/compiler.py 2013-04-09 12:56:07.293736020 +1000
</strong><strong></strong><strong></strong><strong></strong>* class SQLCompiler(object):
<strong>* 296,302 </strong><strong>
--- 296,305 ----
</strong></p>
<blockquote>
<p>
col_aliases.add(c_alias)
aliases.add(c_alias)
</p>
</blockquote>
<blockquote>
<p>
else:
</p>
</blockquote>
<p>
+ m = map(str.isupper, field.column)
</p>
<blockquote>
<p>
r = '%s.%s' % (qn(alias), qn2(field.column))
</p>
</blockquote>
<p>
+ if True in m: # if there is an uppercase, leave it.
+ r = '%s."%s"' % (qn(alias), field.column)
</p>
<blockquote>
<p>
result.append(r)
aliases.add(r)
if with_aliases:
</p>
</blockquote>
<p>
ie. I check if there is an uppercase in the column name, and if so,
I quote the column name, leaving the case as it is ie. mixed.
ie. the column names seem to come in as all lower case and then it
gets converted to uppercase.
I'm not sure what to do if the column names are really all lower case.
</p>
<p>
This was just a quick and dirty fix for my use.
I think maybe a more solid fix might be required but just raising it here in case anybody just wanted a quick fix.
</p>
<p>
A similar problem arises for mixed case table names.
I didnt do a fix for that, yet.
</p>
Resultshttps://code.djangoproject.com/ticket/20226#changeloghttps://code.djangoproject.com/ticket/20414
https://code.djangoproject.com/ticket/20414#20414: Handling of numbers under oracle is slowWed, 15 May 2013 23:50:25 GMTshai<p>
With current code, for all number columns, the Oracle backend asks cx_Oracle to return the numbers as strings, and then transforms them back to numbers on the way out. All this is done because Oracle supports higher precision (and a wider range of integers) than the Python <tt>float</tt> type; some values, if they are to be reported accurately, must be returned as <tt>decimal.Decimal</tt>s, and cx_Oracle doesn't apparently do that on its own.
</p>
<p>
With cx_Oracle 5, though, it is possible to use a much better approach, on a per-column (rather than per-row) basis, selecting the right output type when there is enough information to do so, and making most of the decisions once-per-query instead of once-per-row.
</p>
<p>
An original patch for this was written by Ian Kelly; I improved it and made a pull-request in the stretch towards 1.5, but there was no ticket for it and so it was never merged. I hope we can finally merge it into 1.6.
</p>
<p>
There was a little saga of discussions around this (mostly Anssi, Ian and myself, <a class="ext-link" href="https://groups.google.com/d/topic/django-developers/4BNkJyGez9A/discussion"><span class="icon">​</span>https://groups.google.com/d/topic/django-developers/4BNkJyGez9A/discussion</a>). Some other issues are also mentioned there. But this is the main one.
</p>
<p>
So now there is a ticket. Things changed, and the pull-request needed updating. The new one is at <a class="ext-link" href="https://github.com/django/django/pull/1071"><span class="icon">​</span>https://github.com/django/django/pull/1071</a>.
</p>
Resultshttps://code.djangoproject.com/ticket/20414#changeloghttps://code.djangoproject.com/ticket/21181
https://code.djangoproject.com/ticket/21181#21181: collation specific query results orderingFri, 27 Sep 2013 10:04:46 GMTalan.kesselmann@…<p>
There has been feature request for it in 2012 in django-developers group : <a class="ext-link" href="https://groups.google.com/forum/#!topic/django-developers/0iESVnawNAY"><span class="icon">​</span>https://groups.google.com/forum/#!topic/django-developers/0iESVnawNAY</a>. Before finding that request i asked about same thing in stackoverflow: <a class="ext-link" href="http://stackoverflow.com/questions/18935712/queryset-sorting-specifying-column-collation-for-django-orm-query"><span class="icon">​</span>http://stackoverflow.com/questions/18935712/queryset-sorting-specifying-column-collation-for-django-orm-query</a>. Both Anssi (<a class="ext-link" href="https://groups.google.com/d/msg/django-developers/0iESVnawNAY/JefMfAm7nQMJ"><span class="icon">​</span>https://groups.google.com/d/msg/django-developers/0iESVnawNAY/JefMfAm7nQMJ</a>) and me outline how it could be used im same way:
</p>
<p>
.order_by([fieldnames], collation = 'et_EE')
</p>
<p>
another version of it could be automatical, based on django language settings. Model often has ordering set in its Meta. So why not include automatical ordering there too.
</p>
<p>
Is it possible to include this into some of next versions of Django?
</p>
<p>
<strong>Some background</strong>
</p>
<p>
If django is used to power some international site like a newspaper then there is rarely need for sorting data based on sorting rules of language other than english. If you use it to power a site that hosts data in several languages then you have need to also display data in that language properly. Sorting based on English alphabet does not work correctly in that case cause letters missing from english alphabet (and there are MANY of those letters that exist in swedish, danish, german, not to mention estonian, russian etc. alphabets) are displayed in completely wrong places.
</p>
<p>
Again - most django sites will be probably using single language. But there are many cases that will benefit from this feature. Like e-commerce modules, that translate product names - they can benefit from it. Any site that allows language based naming or translating of their objects will benefit from this feature.
</p>
Resultshttps://code.djangoproject.com/ticket/21181#changeloghttps://code.djangoproject.com/ticket/21544
https://code.djangoproject.com/ticket/21544#21544: Problem with number format when not using L10NMon, 02 Dec 2013 14:03:19 GMTyceruto@…<p>
My system at one point tries to display a number in a specific format, for which I use the "floatformat" filter.
</p>
<p>
My configuration in "settings.py" is:
USE_L10N = False
USE_THOUSAND_SEPARATOR = True
NUMBER_GROUPING = 3
</p>
<p>
The problem is that the "floatformat" filter uses the "format" utility and this in turn applies the grouping of thousands if L10N is true:
</p>
<p>
use_grouping = settings.USE_L10N and settings.USE_THOUSAND_SEPARATOR
</p>
<p>
From the "floatformat" filter I can not force the grouping of thousands, making it impossible to apply this option. Showing my number without the grouping of thousands.
</p>
Resultshttps://code.djangoproject.com/ticket/21544#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/23771
https://code.djangoproject.com/ticket/23771#23771: Optimisation idea for Paginator objectThu, 06 Nov 2014 10:39:35 GMTGP89<p>
I had a thought - I don't know if this can be easily achieved but here it is.
</p>
<p>
I have a view which uses the <tt>Paginator</tt> object to page results for a table, one of the columns of the tables is a total gathered from summing rows from 5 different tables, so the query has 5 joins to get these values.
</p>
<div class="code"><pre>run_objects <span class="o">=</span> Run<span class="o">.</span>objects<span class="o">.</span>filter<span class="p">(</span>type__name<span class="o">=</span>run_type<span class="p">)</span><span class="o">.</span>select_related<span class="p">(</span><span class="s">"runend"</span><span class="p">,</span> <span class="s">"browserlink__browser"</span><span class="p">,</span> <span class="s">"filecheck__filecheckrecord"</span><span class="p">)</span><span class="o">.</span>\
annotate<span class="p">(</span>total_griderror<span class="o">=</span>Count<span class="p">(</span><span class="s">"griderrorrecord"</span><span class="p">,</span> distinct<span class="o">=</span><span class="bp">True</span><span class="p">),</span>
total_gridhttperror<span class="o">=</span>Count<span class="p">(</span><span class="s">"gridhttperrorrecord"</span><span class="p">,</span> distinct<span class="o">=</span><span class="bp">True</span><span class="p">),</span>
total_gridconnerror<span class="o">=</span>Count<span class="p">(</span><span class="s">"gridconnectionerrorrecord"</span><span class="p">,</span> distinct<span class="o">=</span><span class="bp">True</span><span class="p">),</span>
total_storagehttperror<span class="o">=</span>Count<span class="p">(</span><span class="s">"storagehttperrorrecord"</span><span class="p">,</span> distinct<span class="o">=</span><span class="bp">True</span><span class="p">),</span>
total_storageconnerror<span class="o">=</span>Count<span class="p">(</span><span class="s">"storageconnectionerrorrecord"</span><span class="p">,</span> distinct<span class="o">=</span><span class="bp">True</span><span class="p">))</span><span class="o">.</span>order_by<span class="p">(</span><span class="s">"-id"</span><span class="p">)</span>
paginator <span class="o">=</span> Paginator<span class="p">(</span>runs_objects<span class="p">,</span> <span class="mi">15</span><span class="p">)</span>
</pre></div><p>
The <tt>Paginator</tt> object appears to do a Count query, to calculate the total number of pages and then a select query later when a page number is requested to get the data. The problem I'm seeing is that the count query in this case is including the 5 joins which don't affect the count other than making it a lot slower.
</p>
<p>
I was able to speed this up by performing the count for the <tt>Paginator</tt> myself
</p>
<div class="code"><pre>run_objects <span class="o">=</span> Run<span class="o">.</span>objects<span class="o">.</span>filter<span class="p">(</span>type__name<span class="o">=</span>run_type<span class="p">)</span>
total <span class="o">=</span> run_objects<span class="o">.</span>count<span class="p">()</span>
run_objects <span class="o">=</span> run_objects<span class="o">.</span>select_related<span class="p">(</span><span class="s">"runend"</span><span class="p">,</span> <span class="s">"browserlink__browser"</span><span class="p">,</span> <span class="s">"filecheck__filecheckrecord"</span><span class="p">)</span><span class="o">.</span>\
annotate<span class="p">(</span>total_griderror<span class="o">=</span>Count<span class="p">(</span><span class="s">"griderrorrecord"</span><span class="p">,</span> distinct<span class="o">=</span><span class="bp">True</span><span class="p">),</span>
total_gridhttperror<span class="o">=</span>Count<span class="p">(</span><span class="s">"gridhttperrorrecord"</span><span class="p">,</span> distinct<span class="o">=</span><span class="bp">True</span><span class="p">),</span>
total_gridconnerror<span class="o">=</span>Count<span class="p">(</span><span class="s">"gridconnectionerrorrecord"</span><span class="p">,</span> distinct<span class="o">=</span><span class="bp">True</span><span class="p">),</span>
total_storagehttperror<span class="o">=</span>Count<span class="p">(</span><span class="s">"storagehttperrorrecord"</span><span class="p">,</span> distinct<span class="o">=</span><span class="bp">True</span><span class="p">),</span>
total_storageconnerror<span class="o">=</span>Count<span class="p">(</span><span class="s">"storageconnectionerrorrecord"</span><span class="p">,</span> distinct<span class="o">=</span><span class="bp">True</span><span class="p">))</span><span class="o">.</span>order_by<span class="p">(</span><span class="s">"-id"</span><span class="p">)</span>
paginator <span class="o">=</span> Paginator<span class="p">(</span>runs_objects<span class="p">,</span> <span class="mi">15</span><span class="p">)</span>
paginator<span class="o">.</span>_count <span class="o">=</span> total
</pre></div><p>
I was wondering - would it be possible to do this automatically. Is there a way to drop bits off the query for the count query (ie like annotations, select_related, prefetches which would have no effect on the number of rows returned) to speed up things up?
</p>
Resultshttps://code.djangoproject.com/ticket/23771#changeloghttps://code.djangoproject.com/ticket/24632
https://code.djangoproject.com/ticket/24632#24632: PostgreSQL table inheritanceSun, 12 Apr 2015 15:37:18 GMTyennicks<p>
The Django ORM multi-table inheritance approach works by creating a different table for every subclass. For working with these subclasses the ORM uses SQL table joins to query the database. This makes sense for databases such as MySQL and SQLite but not for PostgreSQL.
</p>
<p>
I suggest adding a PostgreSQL specific model that optimizes the ORM behaviour when developing for a PostgreSQL database. This allows for using the PostgreSQL object-relational table approach by the ORM. When implemented, a table used by a subclass inherits from the table used by the superclass, avoiding for example the usage of joins.
</p>
<p>
Another approach is optimizing the default behaviour of the Django ORM but this might impact existing Django implementations that expect traditional multi-table inheritance.
</p>
<p>
PostgreSQL 9.4 manual about table inheritance:
<a class="ext-link" href="http://www.postgresql.org/docs/9.4/static/ddl-inherit.html"><span class="icon">​</span>http://www.postgresql.org/docs/9.4/static/ddl-inherit.html</a>
</p>
Resultshttps://code.djangoproject.com/ticket/24632#changeloghttps://code.djangoproject.com/ticket/24959
https://code.djangoproject.com/ticket/24959#24959: date_interval_sql Implementations for Database Backends Do Not Handle Negative timedelta Objects ProperlyTue, 09 Jun 2015 02:16:39 GMTfredpalmer<p>
If I have a <tt>timedelta</tt> object in python that represents a negative difference, e.g.:
</p>
<pre class="wiki">delta = timedelta(seconds=-3600)
print delta2
-1 day, 23:00:00
</pre><p>
The resultant SQL generated by <tt>date_interval_sql</tt> for the MySQL backend would be something like:
</p>
<pre class="wiki">UPDATE `my_table`
SET ...
`my_datetime` = (`my_table`.`my_datetime` + INTERVAL '-1 0:0:82800:0' DAY_MICROSECOND),
WHERE (...)
</pre><p>
<strong>AND</strong> what we want is the following:
</p>
<pre class="wiki">UPDATE `my_table`
SET ...
`my_datetime` = (`my_table`.`my_datetime` + INTERVAL '-0 0:0:3600:0' DAY_MICROSECOND),
WHERE (...)
</pre><p>
In layman's terms - the two layers are not convertible in a one-to-one sense. A <tt>timedelta</tt> in for the example above in Python means: <strong>go back one day and *add* 23 hours</strong>. So some <tt>datetime + delta</tt> would just subtract one hour.
</p>
<p>
In MySQL, however, <em>INTERVAL '-1 0:0:82800:0' DAY_MICROSECOND</em> means: <strong>add a negative one day and 23 hours</strong>.
</p>
Resultshttps://code.djangoproject.com/ticket/24959#changeloghttps://code.djangoproject.com/ticket/24974
https://code.djangoproject.com/ticket/24974#24974: Cannot create subclass of form created by `modelform_factory()`, e.g. in `ModelAdmin.get_form()`Fri, 12 Jun 2015 06:56:44 GMTmrmachine<p>
The default implementation of <tt>ModelAdmin.get_form()</tt> uses <tt>modelform_factory()</tt> to dynamically create a new <tt>ModelForm</tt> class, and apply form field overrides, etc.
</p>
<p>
The docs mention that I can specify a new base form that is passed to this implementation or just return a new <tt>ModelForm</tt> class. But when designing a generic <tt>ModelAdmin</tt> class that will be used with a number of yet unspecified models, I want to use the form returned by the super class as the base, in case one has already been set on a <tt>ModelAdmin</tt> class my class will be mixed into.
</p>
<p>
I would normally expect that this just works:
</p>
<pre class="wiki">def get_form(self, *args, **kwargs):
form_class = super(MyModelAdmin, self).get_form(*args, **kwargs)
class Form(form_class):
# do stuff.
return Form
</pre><p>
But while <tt>form_class</tt> does all the things like form field overrides, <tt>Form</tt> does not. All form fields are rendered in the admin with regular form widgets, not the admin variants. The reason appears to be because when <tt>Form</tt> is created, <tt>ModelFormMetaclass</tt> is executed again but without the <tt>formfield_overrides</tt> argument.
</p>
<p>
To make it work again, I need to do:
</p>
<pre class="wiki">def get_form(self, *args, **kwargs):
form_class = super(MyModelAdmin, self).get_form(*args, **kwargs)
class Form(form_class):
# do stuff.
kwargs['form'] = Form
return super(MyModelAdmin, self).get_form(*args, **kwargs)
</pre><p>
This runs through the whole default implementation of <tt>get_form()</tt> twice, but it does work.
</p>
<p>
Alternatively, if I wanted to override the <tt>__init__()</tt> method on the form, I could replace it instead of creating a subclass, with something like:
</p>
<pre class="wiki">def get_form(self, *args, **kwargs):
form_class = super(FluentLayoutsMixin, self).get_form(*args, **kwargs)
old_init = form_class.__init__
def new_init(self, *args, **kwargs):
old_init.__get__(self, type(self))(*args, **kwargs)
# do stuff.
form_class.__init__ = new_init.__get__(None, form_class)
return form_class
</pre><p>
This won't execute the default <tt>get_form()</tt> implementation twice, but it's getting pretty hairy.
</p>
<p>
This took three people a few hours to work out, stepping through many <tt>pdb</tt> sessions in django admin and model form code. A note in the docs might save someone else the trouble.
</p>
<p>
Something like:
</p>
<blockquote>
<p>
Note: You cannot just create and return a subclass of form from the super class in this method. Due to the way <tt>ModelFormMetaclass</tt> works, the subclass will ignore <tt>formfield_overrides</tt> unless you pass it back through the default implementation.
</p>
</blockquote>
<pre class="wiki"># NO: `formfield_overrides` not applied.
def get_form(self, *args, **kwargs):
form_class = super(MyModelAdmin, self).get_form(*args, **kwargs)
class Form(form_class):
# do stuff.
return Form
# YES: `formfield_overrides` applied.
def get_form(self, *args, **kwargs):
form_class = super(MyModelAdmin, self).get_form(*args, **kwargs)
class Form(form_class):
# do stuff.
kwargs['form'] = Form
return super(MyModelAdmin, self).get_form(*args, **kwargs)
</pre><p>
This is actually more of a general problem with <tt>modelform_factory()</tt> than a problem with <tt>ModelAdmin.get_form()</tt>, so perhaps a note for the <tt>modelform_factory()</tt> docs instead, with a link to it from the <tt>ModelAdmin.get_form()</tt> docs.
</p>
<p>
Here is an interactive shell session demonstrating the problem with <tt>modelform_factory()</tt>.
</p>
<pre class="wiki">&gt;&gt;&gt; from django import forms
&gt;&gt;&gt; from django.forms.models import modelform_factory
&gt;&gt;&gt; from django.contrib.sites.models import Site
# Create a form class where all fields are converted to `DateTimeField` via callback.
&gt;&gt;&gt; Form = modelform_factory(Site, formfield_callback=lambda f: forms.DateTimeField)
&gt;&gt;&gt; Form.base_fields
OrderedDict([(u'id', &lt;class 'django.forms.fields.DateTimeField'&gt;), ('domain', &lt;class 'django.forms.fields.DateTimeField'&gt;), ('name', &lt;class 'django.forms.fields.DateTimeField'&gt;)])
# Note that for any subclass, all base fields have reverted to their original values, instead of being inherited.
&gt;&gt;&gt; class FooForm(Form): pass
&gt;&gt;&gt; FooForm.base_fields
OrderedDict([('domain', &lt;django.forms.fields.CharField object at 0x112db5f90&gt;), ('name', &lt;django.forms.fields.CharField object at 0x112d74a90&gt;)])
</pre>Resultshttps://code.djangoproject.com/ticket/24974#changeloghttps://code.djangoproject.com/ticket/25173
https://code.djangoproject.com/ticket/25173#25173: Model inheritance and select_relatedSat, 25 Jul 2015 17:50:34 GMTilling2005<p>
I have the following in models and run into strange behavior when i use select_related and model inheritance:
</p>
<p>
Models:
</p>
<pre class="wiki">class A(models.Model):
field_fk = models.ForeignKey('C')
class B(A):
fields_b = models.CharField(max_length=255)
class C(models.Model):
field_c = models.CharField(max_length=255)
</pre><p>
So A has a foreign key to C and B inherits from A. Now I want to query A downcast it to B and read the relationship to C. To minimize sql queries I use select_related:
</p>
<pre class="wiki">obj = A.objects.select_related('b', 'field_fk).first()
obj = obj.b
print(obj.field_fk) # this prints "C object"
</pre><p>
Because I use select_related this should result in just one query. But somehow the information is lost during downcasting and I get to sql queries:
</p>
<pre class="wiki">SELECT ••• FROM "base_a" INNER JOIN "base_c" ON
( "base_a"."field_fk_id" = "base_c"."id" ) LEFT OUTER JOIN "base_b" ON
( "base_a"."id" = "base_b"."a_ptr_id" ) ORDER BY "base_a"."id" ASC LIMIT 1
SELECT ••• FROM "base_c" WHERE "base_c"."id" = 1
</pre><p>
So in the first query looks fine. But I am surprised that I get a second query. Is this a bug in django's ORM or am I doing something wrong?
</p>
<p>
I also posted this at stackoverflow, but I am quite sure that this is a bug.
<a class="ext-link" href="http://stackoverflow.com/questions/31628588/django-model-inheritance-and-select-related"><span class="icon">​</span>http://stackoverflow.com/questions/31628588/django-model-inheritance-and-select-related</a>
</p>
Resultshttps://code.djangoproject.com/ticket/25173#changelog