Django: Ticket Queryhttps://code.djangoproject.com/query?status=!closed&needs_better_patch=0&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&needs_better_patch=0&order=priority
Trac 1.2.2https://code.djangoproject.com/ticket/373
https://code.djangoproject.com/ticket/373#373: Add support for multiple-column primary keysFri, 19 Aug 2005 18:15:29 GMTJacob<p>
In the interest of being able to use Django as an admin interface for <em>any</em> db schema, it really should support multiple column primary keys.
</p>
<p>
Currently, you can "fake" it by declaring one of the keys to be primary in Django and adding a unique constraint to the model. You'd have to do without the auto-generated SQL that Django gives you, but if you're smart enough to know how and why to use multiple primary keys, you can probably write the schema by hand. Still, this is less than ideal.
</p>
<p>
This is likely to be very difficult.
</p>
Resultshttps://code.djangoproject.com/ticket/373#changeloghttps://code.djangoproject.com/ticket/897
https://code.djangoproject.com/ticket/897#897: Bi-Directional ManyToMany in AdminThu, 24 Nov 2005 10:59:37 GMTanonymous<p>
Allow amnytomany relationships to be defined both ways
E.G
</p>
<pre class="wiki">class ItemType(meta.Model):
name = meta.CharField(maxlength=100)
descritpion = meta.CharField(maxlength=250)
class PropertyType(meta.Model):
name = meta.CharField(maxlength=100)
itemtypes = meta.ManyToManyField(ItemType)
</pre><p>
Excellent. When I make a new property type in the admin screens I get a
mutiselect window for item types.
</p>
<p>
What I want to be able to do however is have this work back the other
way too so that whe I create a new item i can specify what property
types apply.
</p>
<p>
Thanks
</p>
Resultshttps://code.djangoproject.com/ticket/897#changeloghttps://code.djangoproject.com/ticket/2137
https://code.djangoproject.com/ticket/2137#2137: Add drag and drop ordering for inlines to set order_with_respect_to in admin interfaceSun, 11 Jun 2006 23:51:21 GMTanonymous<p>
Pre-MR, adding order_with_respect_to would present an ordering field in the admin interface (or a draggable list of inline objects if dom-drag.js was installed). Post M-R, neither appears. Not sure if this is a problem at the template level or at the model level.
</p>
Resultshttps://code.djangoproject.com/ticket/2137#changeloghttps://code.djangoproject.com/ticket/2259
https://code.djangoproject.com/ticket/2259#2259: Primary keys should be readonly by default in adminWed, 28 Jun 2006 19:20:45 GMTed@…<p>
When creating a simple model with a non-integer primary key, the Admin interface shows the field as editable, but when making a change, it seems to execute an incorrect query.
</p>
<p>
For example:
</p>
<pre class="wiki">class Group(models.Model):
name = models.CharField(maxlength=32, primary_key=True)
def __str__(self):
return self.name
class Admin:
list_display = ('name',)
search_fields = ('name',)
</pre><p>
When changing the primary key field (e.g. from 'Test' to 'TestX') when editing a record, a ProgrammingError exception is raised. The SQL that is generated is:
</p>
<pre class="wiki">UPDATE "config_group" SET WHERE "name"='Test'
</pre><p>
This is missing the primary key field to be changed after SET.
</p>
<p>
This is with the latest SVN code. It seems to be an issue around line 179 of db/models/base.py where it only adds the non-pk columns after SET.
</p>
Resultshttps://code.djangoproject.com/ticket/2259#changeloghttps://code.djangoproject.com/ticket/2316
https://code.djangoproject.com/ticket/2316#2316: GenericRelation and get_or_create do not work togetherSun, 09 Jul 2006 18:20:22 GMTRudolph Froger<p>
I think GenericRelation and get_or_create do not work together. Example:
</p>
<p>
baz = Bar.objects.get_or_create(content_object=foo)
</p>
<p>
You get an exception:
Cannot resolve keyword 'content_object' into field
</p>
Resultshttps://code.djangoproject.com/ticket/2316#changeloghttps://code.djangoproject.com/ticket/2361
https://code.djangoproject.com/ticket/2361#2361: QuerySet.filter(m2mfield__isnull=False) may return duplicatesSun, 16 Jul 2006 18:42:51 GMTdaniel.tietze@…<p>
My Django installation is SVN Revision: 3238
</p>
<p>
Filtering models by a ManyToMany field does not appear to work.
See Google groups thread <a class="ext-link" href="http://groups.google.com/group/django-users/browse_thread/thread/d0d799a45cb92d35"><span class="icon">​</span>http://groups.google.com/group/django-users/browse_thread/thread/d0d799a45cb92d35</a>
</p>
<p>
I have two classes -- Blog and Submission:
</p>
<pre class="wiki">class Blog( models.Model ):
entries = models.ManyToManyField( Submission )
class Submission( models.Model ):
[... whatever ]
</pre><p>
I want to fetch a list of all Blog instances which have at least one
Submission , i.e. entries.count() &gt; 0.
</p>
<p>
The suggested
</p>
<pre class="wiki">Blog.objects.filter(entries__isnull = False)
</pre><blockquote>
<p>
(suggested by Malcolm Tredinnick) returns:
</p>
</blockquote>
<pre class="wiki">
psycopg.ProgrammingError: FEHLER: Spalte
m2m_models_blog__entries.entries existiert nicht
SELECT
"models_blog"."id","models_blog"."title","models_blog"."description","models_blog"."region_id","models_blog"."regionname","models_blog"."date_submitted","models_blog"."author_id","models_blog"."visible"
FROM "models_blog" LEFT OUTER JOIN "models_blog_entries" AS
"m2m_models_blog__entries" ON "models_blog"."id" =
"m2m_models_blog__entries"."blog_id" WHERE
("m2m_models_blog__entries"."entries" IS NOT NULL)
</pre><p>
m2m_models_blog<span class="underline">entries is an alias for models_blog_entries -- I
*have* this table, but it has no column "entries". This is what it looks like:
</span></p>
<pre class="wiki"># \d models_blog_entries
Tabelle »public.models_blog_entries«
Spalte | Typ | Attribute
---------------+---------+---------------------------------------------------------------------
id | integer | not null default
nextval('public.models_blog_entries_id_seq'::text)
blog_id | integer | not null
submission_id | integer | not null
Indexe:
»models_blog_entries_pkey« PRIMARY KEY, btree (id)
»models_blog_entries_blog_id_key« UNIQUE, btree (blog_id,
submission_id)
Fremdschlüssel-Constraints:
»models_blog_entries_blog_id_fkey« FOREIGN KEY (blog_id)
REFERENCES models_blog(id)
»models_blog_entries_submission_id_fkey« FOREIGN KEY
(submission_id) REFERENCES models_submission(id)
</pre><p>
Also, if I do this:
</p>
<pre class="wiki">Blog.objects.filter(entries__blog__id__isnull = False)
</pre><p>
I get a list of Blogs which have entries, however I have duplicates in
the list, one for each Submission which is in a M2M relationship (i.e.
each Blog is shown n times if it has n entries).
</p>
Resultshttps://code.djangoproject.com/ticket/2361#changeloghttps://code.djangoproject.com/ticket/3006
https://code.djangoproject.com/ticket/3006#3006: generic relations do not act as expected in a filter/getWed, 08 Nov 2006 16:41:24 GMTjeroen_at_lbvd.nl<p>
If I have a model like this:
</p>
<pre class="wiki">class SecurityContext(models.Model):
title = models.CharField(maxlength=100)
description = models.TextField()
class AccessList(models.Model):
principal_id = models.PositiveIntegerField()
principal_ct = models.ForeignKey(ContentType)
security_context = models.ForeignKey(SecurityContext)
principal = models.GenericForeignKey(fk_field="principal_id", ct_field="principal_ct")
permission = models.ForeignKey(Permission)
class Admin:
pass
class MyModel(models.Model):
security_context = models.ForeignKey(SecurityContext)
owner = models.ForeignKey(User)
my_field = models.CharField(maxlength=50)
class Admin:
pass
</pre><p>
Then I expect to be able to do something like:
</p>
<pre class="wiki">my_model_instance.security_context.accesslist_set.filter(principal=user_object)
</pre><p>
and have it return a list of all accesslist entries for the given principal (similar to ForeignKeys or M2M relations).
Instead I get an error stating: Cannot resolve keyword 'principal' into field.
</p>
<p>
The following does work however:
</p>
<pre class="wiki">my_model_instance.security_context.accesslist_set.filter(principal_id=user_object.id)
</pre>Resultshttps://code.djangoproject.com/ticket/3006#changeloghttps://code.djangoproject.com/ticket/3254
https://code.djangoproject.com/ticket/3254#3254: full text search support for postgres, oracle and mssqlMon, 08 Jan 2007 19:12:47 GMTRonny Pfannschmidt<p>
I didn't like it was missing.
</p>
<p>
oracle, mssql : add a FulltextIndex for the Fields
</p>
<p>
postgresql: for each FulltextField add a extra tsvector Field named like <code>"%(fieldname)_tsv"</code>
</p>
<p>
Problems with sqlite fts:
</p>
<ul><li>they stated a match statement may only be used once in a query
</li><li>it needs a very specific syntax to search multiple fields
</li><li>i have no idea how to get that into the ORM
</li></ul>Resultshttps://code.djangoproject.com/ticket/3254#changeloghttps://code.djangoproject.com/ticket/3461
https://code.djangoproject.com/ticket/3461#3461: DatabaseWrapper should pass through args and kwargs to underlying database adapterThu, 08 Feb 2007 20:38:52 GMTJack Moffitt <metajack@…><p>
Currently the DatabaseWrapper (at least for the postgresql) does not pass args and kwargs for cursor() calls to the underlying database adapter. This makes it impossible to use the adapter fully at the low level. For example, to use dict cursors in psycopg2 you have to pass a different cursor factory via the cursor_factory keyword argument to cursor(). The attached patch passes through args and kwargs for cursor() calls.
</p>
Resultshttps://code.djangoproject.com/ticket/3461#changeloghttps://code.djangoproject.com/ticket/3569
https://code.djangoproject.com/ticket/3569#3569: extend Atom feed support for other fieldsSun, 25 Feb 2007 04:06:58 GMTjtauber@…<p>
At present, Atom feed support is limited to a small number of fields and it is difficult to do things like generate full-content feeds.
</p>
<p>
I'm offering to improve Atom feed support by implementing the full range of RFC 4287 elements.
</p>
Resultshttps://code.djangoproject.com/ticket/3569#changeloghttps://code.djangoproject.com/ticket/4140
https://code.djangoproject.com/ticket/4140#4140: oracle: manage.py syncdb fails with ORA-06552 when a fieldname is a keywordTue, 24 Apr 2007 08:51:38 GMTfrank.hoffsummer@…<p>
calling "manage.py syncdb log" with my log model on an empty Oracle database yields the following exception
</p>
<pre class="wiki">Traceback (most recent call last):
File "./manage.py", line 11, in ?
execute_manager(settings)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/core/management.py", line 1730, in execute_manager
execute_from_command_line(action_mapping, argv)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/core/management.py", line 1627, in execute_from_command_line
action_mapping[action](int(options.verbosity), options.interactive)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/core/management.py", line 573, in syncdb
cursor.execute(statement)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/db/backends/util.py", line 13, in execute
return self.cursor.execute(sql, params)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/db/backends/oracle/base.py", line 104, in execute
return Database.Cursor.execute(self, query, params)
cx_Oracle.DatabaseError: ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-320: the declaration of the type of this expression is incomplete or malformed
</pre><p>
the model myapp/log/models.py is simple and causes no problem in MySQL, I attached it to this ticket.
a subsequent, second run of manage py syncdb goes without error.
</p>
Resultshttps://code.djangoproject.com/ticket/4140#changeloghttps://code.djangoproject.com/ticket/4147
https://code.djangoproject.com/ticket/4147#4147: Add some i18n hooks to DateFormatWed, 25 Apr 2007 00:37:53 GMTorestis<p>
Django's handling of i18n is fairly good, but one major point that it doesn't handle well (together with almost everything else out there) is the formatting of dates.
</p>
<p>
The most obvious example is the display of the month names. While in English there is only one case of nouns, in many other european languages there are more, which have different spellings.
For example, in Greek, in order to be able to diplay full-word months and capture all possible sentence formats, one needs three cases:
</p>
<ol><li>The subjective case (eg. en: January, 2007 - el: <strong>Ιανουάριος</strong>, 2007)
</li><li>The posessive case (eg. en: 23th of January - el: 23η <strong>Ιανουαρίου</strong>)
</li><li>The objective case (eg. en: Entries posted on January - el: Δημοσιεύσεις που έγιναν τον <strong>Ιανουάριο</strong>)
</li></ol><p>
I'm sure this is common in most european languages, but I'm not an expert; Please everybody comment on this.
</p>
<p>
To implement this in django, I suggest the following:
</p>
<ul><li>Add MONTHS_POS, MONTHS_OBJ to django.utils.dates. This should read "of January" and "on January" in english .
</li><li>Add a custom extension in django.utils.dateformat: Q for MONTHS_POS, V for MONTHS_OBJ. Any available letter should do.
</li></ul><p>
That's all. There is a=still an issue about the format 'S' that adds the ordinals (1st, 2nd etc) but I don't know how other languages deal with this.
</p>
<p>
I can submit a patch for this...
</p>
Resultshttps://code.djangoproject.com/ticket/4147#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/5147
https://code.djangoproject.com/ticket/5147#5147: Translation inconsistency for Hungarian language (entry - entries)Mon, 13 Aug 2007 12:39:55 GMTSzilveszter Farkas <szilveszter.farkas@…><p>
I'm building a site right now for a Hungarian customer, so I had to revise the Hungarian translation, and also review the UI bits. There is a small inconsistency I've found, which is pretty important for the Hungarian language (I don't know if this is an issue for other languages, too).
</p>
<p>
So there is a verbose_name and a verbose_name_plural field in the Meta class of a model. The verbose_name_plural field is used in two different contexts: once you can see it in the admin homepage (let's say "Entries" - the same applies to the permissions list), and you see it on the listing page ("2 entries"). The problem is that these two words are the same in English, but not in Hungarian. Remaining at our example: the homepage should say "Bejegyzések" (plural form), and the listing should say "2 bejegyzés" (we don't use the plural form after counts).
</p>
<p>
I hope you can fix the issue. A possible fix: use the verbose_name_plural on the listing page, and introduce a descriptive_name (or something similar) field for the admin index/permissions list.
</p>
Resultshttps://code.djangoproject.com/ticket/5147#changeloghttps://code.djangoproject.com/ticket/5349
https://code.djangoproject.com/ticket/5349#5349: Shouldn't the item_enclosure_url automatically prefixed with the current site?Thu, 06 Sep 2007 11:53:12 GMTanonymous<p>
I'd recommend to add a call to add_domain() to the enclosure URL because other URLs are also automatically extended with the site's URL. I've included the patch.
</p>
Resultshttps://code.djangoproject.com/ticket/5349#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/5518
https://code.djangoproject.com/ticket/5518#5518: Capitalized verbose names for modelsMon, 17 Sep 2007 01:01:45 GMTPetr Marhoun <petr.marhoun@…><p>
There is a difference between models and forms, now the preferred format is:
</p>
<div class="wiki-code"><div class="code"><pre><span class="k">class</span> <span class="nc">Contact</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
email <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>verbose_name<span class="o">=</span>_<span class="p">(</span><span class="s1">'email'</span><span class="p">))</span>
<span class="k">class</span> <span class="nc">ContactForm</span><span class="p">(</span>forms<span class="o">.</span>Form<span class="p">):</span>
email <span class="o">=</span> forms<span class="o">.</span>CharField<span class="p">(</span>label<span class="o">=</span>_<span class="p">(</span><span class="s1">'Email'</span><span class="p">))</span>
</pre></div></div><p>
Why is once 'email' and once 'Email'? I think it is quite
inconsistent.
</p>
<p>
But it is specially bad for translators. Example: I have a model with
ten fields. I use form_for_model and form_for_instance. I realize that
I need a form with seven fields from model and some new fields. So I
have to translate the fields again - gettext doesn't know that 'email'
is similar to 'Email'.
</p>
<p>
I think it should be possible (not necessary) to use capitalized
verbose names in models. It means to uncapitalized some words in admin
</p>
<ul><li>but it is possible, I do it in my personal branch.
</li></ul><p>
I thought that this kind of change should be sent to django-developers mailing list first. But there was no answer so there is a ticket.
</p>
<p>
Ticket <a class="closed ticket" href="https://code.djangoproject.com/ticket/5426" title="#5426: [newforms-admin] - uncapfirst tag and utility function (closed: wontfix)">#5426</a> is precondition for it.
</p>
<p>
I would like to create patch - if you think that it can be applied.
</p>
Resultshttps://code.djangoproject.com/ticket/5518#changeloghttps://code.djangoproject.com/ticket/5745
https://code.djangoproject.com/ticket/5745#5745: MySQL Collations/Charsets and EnginesFri, 12 Oct 2007 21:51:23 GMTArmin Ronacher<p>
Django should really have a DATABASE_CHARSET / DATABASE_COLLATION setting in the settings.py as well as a setting for the mysql database engine. It's stunning that unittests can enforce a database collation but tables not. Also an argument in the Meta section of models that allows to define the collation, charset and engine would be an important thing to have.
</p>
<p>
I know that there are workarounds for those limitations but they have all disadvantages.
</p>
Resultshttps://code.djangoproject.com/ticket/5745#changeloghttps://code.djangoproject.com/ticket/5793
https://code.djangoproject.com/ticket/5793#5793: Allow custom attributes in Meta classesMon, 22 Oct 2007 11:41:50 GMTeikke@…<p>
In some cass it is useful to be able to store meta information on models inside the model class. In Django the Meta subclass is used to achieve this. Trying to add a custom attribute to a model's Meta inner class results in an exception though, thrown from django.db.models.options, which does indeed check any valid attribute names and raises an exception when unknown names are found.
Is there any reason for this somewhat strange behaviour, not to allow a developer to add non-standard meta information to a model class (which can later on be used in eg view code)?
</p>
<p>
Thanks!
</p>
Resultshttps://code.djangoproject.com/ticket/5793#changeloghttps://code.djangoproject.com/ticket/5899
https://code.djangoproject.com/ticket/5899#5899: Allow admin fieldsets to be collapsible but not initially collapsedThu, 08 Nov 2007 14:08:08 GMTIonut Ciocirlan <ionut.ciocirlan@…><p>
I want to use the collapse feature of the admin, but not have the field initially collapsed, so I made this little patch.
</p>
<p>
It adds a "collapsible" class that does just that. It also patches the documentation.
</p>
Resultshttps://code.djangoproject.com/ticket/5899#changeloghttps://code.djangoproject.com/ticket/5929
https://code.djangoproject.com/ticket/5929#5929: Allow Fields to use multiple db columns (complex datatypes)Mon, 12 Nov 2007 23:00:59 GMTDaniel Poelzleithner<p>
Currently it seems that it is not possible to have complex db filds. For example:
<a class="ext-link" href="https://dev.leipzig.freifunk.net/trac/browser/ffsomething/branches/generic/apps/management/models.py"><span class="icon">​</span>Implementation of a IP model</a> which actually should be a field type not a model. The implementation is not clean, because foreign key lookups for example do not work. The model maps for example:
</p>
<pre class="wiki">NetworkAddress.objects.filter(ip__in="192.168.0.10/16")
</pre><p>
into a complex query for a ip resisting in a network range.
</p>
<p>
Due the fact that model fields can only map to one db column, many complex data types can't be implemented. For example a ipv6 ip address which is a 128 bit value can't be handled by most db implementations of integer fields, so it has to be expanded to multiple columns plus a additional netmask column. Using varchar doesn't work because there is no way to search for network ranges or IPs in ranges, etc...
I think a field should be able to implement lookup mappings which can be overridden to implement complex datatypes as well as use multiple db fields.
</p>
Resultshttps://code.djangoproject.com/ticket/5929#changeloghttps://code.djangoproject.com/ticket/6135
https://code.djangoproject.com/ticket/6135#6135: Introduce a short-cut for template filters that has needs_autoescape = TrueWed, 05 Dec 2007 16:04:43 GMTanonymous<p>
After the autoescaping was introduced I had to rewrite all filters to comform new requirements: put is_safe=True and needs_autoescape=True where needed.
<br />
I have written about 25 filters that have needs_autoescape=True and absolutely of them contained contained the same strings
</p>
<pre class="wiki">
def filter(text, autoescape=None):
if autoescape:
esc = conditional_escape
else:
esc = lambda x: x
text = esc(text)
# Then goes the part which is different for all filters
#
#
return mark_safe(result)
</pre><p>
I have checked the filters in django. All the same.
I think it is way to much of writting.
</p>
<p>
I propose to split property needs_autoescape = True on two properties:<br />
</p>
<p>
needs_manual_autoescape = True, then Do all the stuff above, manually.<br />
</p>
<p>
needs_autoescape = True, then all above steps will do template system for user. All this thinks can do a simple decorator as well.
</p>
Resultshttps://code.djangoproject.com/ticket/6135#changeloghttps://code.djangoproject.com/ticket/6343
https://code.djangoproject.com/ticket/6343#6343: % symbols not escaped in db_column column names when preparing queriesTue, 08 Jan 2008 12:47:24 GMTDaniel Pope <dan@…><p>
Using <code>%</code> in database column names (specified using <code>db_column</code>) causes the database wrapper to fail when preparing queries.
</p>
<p>
This is because the <code>%</code> symbol is not properly quoted (as <code>%%</code>), and conflicts with the usage of <code>%s</code> for passing parameters to queries.
</p>
<p>
I am attaching a patch for the MySQL backend where I encountered the issue; I'm not sure if other backends exhibit this bug because it presumably depends both on whether the database's native capability to support <code>%</code> characters in column names, and on the <a class="ext-link" href="http://www.python.org/dev/peps/pep-0249/"><span class="icon">​</span>Python DB-API</a> <code>paramstyle</code>.
</p>
Resultshttps://code.djangoproject.com/ticket/6343#changeloghttps://code.djangoproject.com/ticket/6363
https://code.djangoproject.com/ticket/6363#6363: Login page is redisplayed without any message if AdminSite.has_permission() returns FalseFri, 11 Jan 2008 19:15:42 GMTMichel Sabchuk<p>
I found a bug when using the has_permission method of the AdminSite class to filter which users can access the admin page:
</p>
<pre class="wiki">class SuperuserAdminSite(admin.AdminSite):
def has_permission(self, request):
return super(SuperuserAdminSite, self).has_permission(request) and request.user.is_superuser
admin_site = SuperuserAdminSite()
</pre><p>
When I try to log on a user that is not a superuser, it already get the login but stay on the login page (with the header but no application loaded), I think this is a bug :) The user should get a error message as if it passed a wrong password or such, isn´t it?
</p>
Resultshttps://code.djangoproject.com/ticket/6363#changeloghttps://code.djangoproject.com/ticket/6489
https://code.djangoproject.com/ticket/6489#6489: Add selected and enabled_from for JS calendarMon, 28 Jan 2008 16:17:07 GMTBastian Kleineidam <calvin@…><p>
Add two parameters to the JS calendar class: highlighting a
selected date, and disabling dates before a specified one.
</p>
Resultshttps://code.djangoproject.com/ticket/6489#changeloghttps://code.djangoproject.com/ticket/6517
https://code.djangoproject.com/ticket/6517#6517: MySQL: manage.py dbshell does not get charset from DATABASES settingThu, 31 Jan 2008 08:42:34 GMTTom Vergote<p>
I noticed that manage.py dbshell doesn't respect the database_options.<br />
I ran into an issue with an application we are creating that needs to support mysql and postgre at least, we execute some sql scripts that get piped to manage.py dbshell (to avoid hardcoding psql -U xxx or mysql -u xxx and creating 2 scripts every time).
</p>
<p>
When running an utf8 database with utf8 as our charset in database_options, we ran into some weird encoding issues.
</p>
<p>
The solution for us was to learn mysql/client.py to respect the encoding settings in settings.py
</p>
<p>
Are you opposed to something like this?
</p>
<p>
Attaching small patch that fixes our problem. Let me know if it needs extending to support other backends or database_options.
</p>
Resultshttps://code.djangoproject.com/ticket/6517#changeloghttps://code.djangoproject.com/ticket/6785
https://code.djangoproject.com/ticket/6785#6785: QuerySet.get() should only attempt to fetch a limited number of rowsSat, 15 Mar 2008 18:47:07 GMTBrantley<p>
.get() selects and lists every record in the db matching the given filter, when it only needs to select two at most.
</p>
Resultshttps://code.djangoproject.com/ticket/6785#changeloghttps://code.djangoproject.com/ticket/6933
https://code.djangoproject.com/ticket/6933#6933: You cannot search with spaces if search_fields is declared with "^"Mon, 31 Mar 2008 21:52:58 GMTMartín Conte Mac Donell <Reflejo@…><p>
That is. When search_fields is declared to "starts with" you cannot perform queries with spaces.
</p>
<p>
File contrib/admin/views/main.py; Line 326:
</p>
<pre class="wiki">for bit in self.query.split():
or_queries = [models.Q(**{construct_search(field_name): bit}) for field_name in self.search_fields]
other_qs = QuerySet(self.model)
(...)
qs = qs &amp; other_qs
</pre><p>
So, if for example i'm looking for "Hey dud" query will be:
</p>
<pre class="wiki">qs.filter(field__startswith="Hey") &amp; qs.filter(field__startswith("dud"))
</pre>Resultshttps://code.djangoproject.com/ticket/6933#changeloghttps://code.djangoproject.com/ticket/7018
https://code.djangoproject.com/ticket/7018#7018: Make ModelForm multiple inheritance possibleMon, 14 Apr 2008 15:57:59 GMTbear330<p>
If I have two ModelForm:
</p>
<pre class="wiki">
class AForm(ModelForm):
class Meta:
model = A
class BForm(ModelForm):
class Meta:
model = B
class CForm(AForm, BForm):
pass
</pre><p>
This doesn't work because of the code:
</p>
<pre class="wiki"> declared_fields = get_declared_fields(bases, attrs, False)
</pre><p>
in ModelFormMetaclass.
</p>
<p>
I can to this to make it work:
</p>
<pre class="wiki"># Because ModelFormMetaclass will call get_declared_fields method with
# with_base_fields=False, we modify it with True.
from django.newforms import models as nmodels
gdf = nmodels.get_declared_fields
nmodels.get_declared_fields = \
lambda bases, attrs, with_base_fields: gdf(bases, attrs, True)
</pre><p>
But it will be nice if this behavior is default behavior.
</p>
<p>
Thanks.
</p>
Resultshttps://code.djangoproject.com/ticket/7018#changeloghttps://code.djangoproject.com/ticket/7497
https://code.djangoproject.com/ticket/7497#7497: AppAdmin class for customizing app listing in admin indexWed, 18 Jun 2008 18:03:33 GMTmrts<p>
See <a class="ext-link" href="http://code.djangoproject.com/wiki/DjangoSpecifications/NfAdmin/FlexibleAppHandling"><span class="icon">​</span>http://code.djangoproject.com/wiki/DjangoSpecifications/NfAdmin/FlexibleAppHandling</a> for details.
</p>
<p>
This <strong>supplements</strong> the <code>app</code> directive.
</p>
<p>
As discussed with <code>brosner</code> and <code>jkocherhans</code> in #django-dev:
</p>
<pre class="wiki">&lt;brosner&gt; it looks reasonable, but haven't spent much time thinking about it
&lt;jkocherhans&gt; mrts: I think this is clearly backwards incompatible with the current nfa api and has to go in pre 1.0 if it goes in at all
&lt;jkocherhans&gt; I'm a big -1 on the order attribute and -0 on models (maybe just a different syntax), but the other stuff seems reasonable
&lt;mrts&gt; jkocherhans: what's wrong with ordering?
&lt;jkocherhans&gt; it just feels like the wrong place to specify it
&lt;jkocherhans&gt; it's a global issue, and an issue any particular app should handle
&lt;mrts&gt; my use case: I have a lot of functionality exposed to somewhat dumb users
&lt;mrts&gt; and they have trouble finding the right bits in the admin interface
ordering is only used in context of admin index
I would like to put the important apps to top and collapse the rest
&lt;jkocherhans&gt; exactly. what should 3rd party apps put there? therein lies my objection.
&lt;mrts&gt; well, I'd say decouple admin from models (as nfa already does) and don't specify any admin options at all -- users are free to customize things with AppAdmin
&lt;jkocherhans&gt; I guess not if using a AppAdmin class is optional. I was originally thinking it would replace model registration with an admin site.
&lt;mrts&gt; jkocherhans: yeah, that's what I kinda meant... it looks more coherent this way
jkocherhans: and it may solve some of the issues register() currently has
&lt;jkocherhans&gt; mrts: I'm gonna have to let it sit for awhile. I'm trying to think of what else an AdminApp class would do besides being a coathanger for a few attributes, nothing is coming to mind.
&lt;mrts&gt; jkocherhans: but jezdez has a point -- it would also provide easy bridging for app instances
</pre><p>
Example syntax follows.
</p>
<pre class="wiki">class BarModelAdmin(admin.ModelAdmin):
description = 'A bar is a bar is a bar'
...
class FooAppAdmin(admin.AppAdmin):
app = settings.INSTALLED_APPS[0]
name = "Foo" # overrides app().name
description = "An application that does foo"
style = {'classes' : ('collapse',)}
order = 1
models = ( # model order in this list determines their display order in app block
(BarModel, BarModelAdmin),
(BazModel, None), # use default ModelAdmin, don't show description
)
admin.site.register(FooAppAdmin) # no need for the tedious for model in [A, B, C, D]: admin.site.register(model)
</pre>Resultshttps://code.djangoproject.com/ticket/7497#changeloghttps://code.djangoproject.com/ticket/7537
https://code.djangoproject.com/ticket/7537#7537: Make RegexURLResolver easier to subclassWed, 25 Jun 2008 15:17:46 GMTKenneth Arnold<p>
Referencing <a class="ext-link" href="http://groups.google.com/group/django-developers/browse_thread/thread/e16bcd24f9e27062"><span class="icon">​</span>the django-developers discussion</a>, here's some simple patches to make the URL resolver easier to customize.
</p>
<p>
First is a nearly minimal patch to convert the url_patterns property to an accessor, get_url_patterns, to ease subclassing, and make the other methods use that consistently instead of duplicating its functionality. With only this patch you can make your own URL resolver without duplicating code, but it's still not clean.
</p>
<p>
The second patch cleans up the situation by abstracting the core functionality of a regex URL resolver into <code>BaseRegexURLResolver</code>.
</p>
<p>
The third patch is an example of how newforms-admin might use this for URL dispatching. I don't have a deep understanding about what's going on, so treat what I did just as an example. Perhaps the cleanest way to accomplish some of what the old ad-hoc resolver did is to override <code>resolve</code>, and if <code>super().resolve</code> returns None, do the ad-hoc stuff.
</p>
<p>
You'd use a custom resolver in your urlconf like this:
</p>
<pre class="wiki">urlpatterns += [AdminSite(r'^admin/')]
</pre><p>
i.e., like a normal <code>include</code> (at least, what that <code>include</code> looks like under the hood).
</p>
<p>
The newforms-admin change would be backwards-incompatible, so if people think it's a good idea, it should get a separate ticket.
</p>
<p>
About the accessor: properties don't inherit well. Could add a <code>url_patterns = property(lambda self: self.get_url_patterns())</code> if that's not too ugly.
</p>
Resultshttps://code.djangoproject.com/ticket/7537#changeloghttps://code.djangoproject.com/ticket/7556
https://code.djangoproject.com/ticket/7556#7556: inspectdb fails in MySql if a table references a table outside the current schemaFri, 27 Jun 2008 15:32:35 GMTbrockweaver<p>
If a table contains a foreign key that refers to another table that sits outside the schema, that index includes a '.' in the table name. Suppose our current schema is <code>schema1</code>:
</p>
<pre class="wiki">CREATE TABLE `T1` (
`ACID` int(8) unsigned NOT NULL,
`SITE` varchar(8) character set latin1 default NULL,
CONSTRAINT `FK_T1_SITE` FOREIGN KEY (`SITE`) REFERENCES `schema2`.`site` (`SITE`)
)
</pre><p>
For this situation, inspectdb will return something similar to this:
</p>
<pre class="wiki">_mysql_exceptions.ProgrammingError: (1146, "Table 'schema1.site' doesn't exist")
</pre><p>
So it tries to use <code>schema1.site</code> as the table to introspect instead of the appropriate <code>schema2</code>.<code>site</code> Notice it not only needs to use the schema as part of the table name, but also not quote the '.'. Also, introspection.py was not pulling the schema name and just assuming the current schema, which for most cases is right, but in this case causes issues for legacy databases.
</p>
Resultshttps://code.djangoproject.com/ticket/7556#changeloghttps://code.djangoproject.com/ticket/7664
https://code.djangoproject.com/ticket/7664#7664: MultiWidget to support named sub widgetsMon, 07 Jul 2008 20:02:01 GMTCollin Anderson<p>
It would be nice if MultiWidget would support names for its sub widgets.
</p>
<p>
Currently if
</p>
<pre class="wiki">widgets = (TextInput(attrs=attrs), TextInput(attrs=attrs))
</pre><p>
you get something like this:
</p>
<pre class="wiki">&lt;input type="text" name="name_0"&gt;&lt;input type="text" name="name_1"&gt;
</pre><p>
Which is a bit ugly.
</p>
<p>
I would like to see something like one of these:
</p>
<pre class="wiki">widgets = (TextInput(attrs=attrs), TextInput(attrs=attrs))
names = ('date', 'time')
</pre><p>
or
</p>
<pre class="wiki">widgets = (('date', TextInput(attrs=attrs)), ('time', TextInput(attrs=attrs)))
</pre><p>
These would render to something like this:
</p>
<pre class="wiki">&lt;input type="text" name="name_date"&gt;&lt;input type="text" name="name_time"&gt;
</pre>Resultshttps://code.djangoproject.com/ticket/7664#changeloghttps://code.djangoproject.com/ticket/7835
https://code.djangoproject.com/ticket/7835#7835: Provide the ability for model definitions that are only availably during testingSat, 19 Jul 2008 14:41:05 GMTRussell Keith-Magee<p>
A current limitation of the unit test framework is that there is no capacity to define 'test models' - that is, models that are only required for the purposes of testing. A regular installation would not know anything about these models - only a test database would have access to them.
</p>
<p>
There are several existing applications that have a need for this capability: For example:
</p>
<ul><li>contrib.admin: you can't test the way admin handles models without some models to handle.
</li><li>contrib.databrowse: you can't test the way the browser works without having models to browse
</li><li>Django Evolution: you can't evolve models without having some models to evolve.
</li></ul><p>
The easiest way to work around this at present is to have a standalone test project which exercises the required functionality. However, these tests aren't integrated into the automated test suite, so they.
</p>
<p>
Another option is to do some app_cache munging during the test - this works, but is very messy.
</p>
<p>
Django should provide a way for model definitions to be defined as part of the test definition, synchronized as part of the test setup, populated and manipulated during test execution, and destroyed along with the test database.
</p>
Resultshttps://code.djangoproject.com/ticket/7835#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/8264
https://code.djangoproject.com/ticket/8264#8264: Replace get_absolute_url with more sane alternativeTue, 12 Aug 2008 20:10:47 GMTsimon<p>
See <a class="ext-link" href="http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl"><span class="icon">​</span>http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl</a>
</p>
Resultshttps://code.djangoproject.com/ticket/8264#changeloghttps://code.djangoproject.com/ticket/8307
https://code.djangoproject.com/ticket/8307#8307: ImageFile use of width_field and height_field is slow with remote storage backendsThu, 14 Aug 2008 07:05:43 GMTsebastian.serrano@…<p>
im attaching a patch that could make it work
</p>
Resultshttps://code.djangoproject.com/ticket/8307#changeloghttps://code.djangoproject.com/ticket/8472
https://code.djangoproject.com/ticket/8472#8472: Add "Recent Actions" panel to app_index templateThu, 21 Aug 2008 15:58:44 GMTJulia<p>
This was a feature request and relates to the changeset in <a class="ext-link" href="http://code.djangoproject.com/ticket/1390"><span class="icon">​</span>#1390</a>. The goal is to produce specified results for the Recent Actions panel (sidebar) to only display logged actions for that particular model. For example, at Home &gt; Auth would only display logged actions for the apps pertaining to that model (e.g. User, Groups).
</p>
Resultshttps://code.djangoproject.com/ticket/8472#changeloghttps://code.djangoproject.com/ticket/8972
https://code.djangoproject.com/ticket/8972#8972: Add ability to delete selected vector features within the Geodjango/OpenLayers Admin map interfaceMon, 08 Sep 2008 17:35:43 GMTspringmeyer<p>
This feature has been needed for some time, and was recently requested. See: <a class="ext-link" href="http://groups.google.com/group/django-users/browse_thread/thread/36242edfd0d0281c?hl=en"><span class="icon">​</span>http://groups.google.com/group/django-users/browse_thread/thread/36242edfd0d0281c?hl=en</a>
</p>
<p>
I've started a basic patch that adds a javascript function to allow multiple features to be selected in the map interface, deleted from view, and removed from the save method.
</p>
<p>
I've tested this so far when editing multipolygon data in the admin.
</p>
<p>
A known issue I'm hoping others may have a solution to:
</p>
<p>
Currently, an OL javascript error occurs on line 948 of OpenLayer.js after successfully deleting a feature. This do not seem to cause any problems in saving the correct geometry or in continuing to use the select control. This is the firebug output:
</p>
<pre class="wiki">object is undefined
selectFeature()(undefined)OpenLayers.js (line 948)
clearSelectedFeatures()()277 (line 327)
javascript:geodjango_geometry.clearSelectedFeatures()()()javascri...eatures() (line 1)
[Break on this error] this.feature=null;this.dragControl.deact...ply(this.selectControl,[this.feature]);}
</pre>Resultshttps://code.djangoproject.com/ticket/8972#changeloghttps://code.djangoproject.com/ticket/9076
https://code.djangoproject.com/ticket/9076#9076: Inline forms can result in a "Please correct the errors below." message with no errors listed.Sat, 13 Sep 2008 20:27:26 GMTcoady<p>
This error can reproduced with the poll app in the tutorial with a minor change. Remove the choice field from the Choice model (file attached). Edit a poll by adding two choices; enter any numbers in the votes fields. Any subsequent save will result in the "Please correct the errors below." message with no highlighted errors.
</p>
<p>
The problem occurs in BaseModelFormSet._construct_form where an index access on the queryset is returning duplicate pks. This in turn leads to validation failing in BaseModelForm.validate_unique. The error occurs in 1.0 and the trunk, probably introduced around the time core=True was removed.
</p>
Resultshttps://code.djangoproject.com/ticket/9076#changeloghttps://code.djangoproject.com/ticket/9107
https://code.djangoproject.com/ticket/9107#9107: URL arguments to set values of fields in admin don't work for inlinesTue, 16 Sep 2008 18:06:39 GMTjosh@…<p>
Though it works just fine to set the value of a field in the admin with URL arguments (i.e. adding '?title=foo' to your URL sets the value of the field 'title' to 'foo'), this doesn't work if the field you're trying to set is in an inline. In such a case the syntax would presumably be something along the lines of '?inlinemode_set-0-fieldname' if you were trying to set the value fo the first instance of the inline model. This, however, doesn't work nor does any other variation I was able to think of.
</p>
Resultshttps://code.djangoproject.com/ticket/9107#changeloghttps://code.djangoproject.com/ticket/9173
https://code.djangoproject.com/ticket/9173#9173: Conditional content of template blocksMon, 22 Sep 2008 14:07:21 GMTAndrei Khitrov<p>
It will be very good if there is some possibility to mark sort of "conditional content" of the template blocks ({% block .. %}), that is the content that is displayed only if in a child template the block has some content. For instance, we have 2 templates:
</p>
<pre class="wiki">parent.html
&lt;table&gt;
&lt;tr&gt;
&lt;td&gt;{% block firstcol %}{% endblock %}&lt;/td&gt;
&lt;td&gt;{% block secondcol %}{% endblock %}&lt;/td&gt;
{% block thirdcol %}&lt;td&gt;{% blockcontent %}&lt;/td&gt;{% endblock %}
&lt;/tr&gt;
&lt;/table&gt;
</pre><pre class="wiki">child.html
{% extends 'parent.html' %}
{% block firstcol %} 1 {% endblock %}
{% block firstcol %} 2 {% endblock %}
</pre><p>
We should have such an output text:
</p>
<pre class="wiki">&lt;table&gt;
&lt;tr&gt;
&lt;td&gt; 1 &lt;/td&gt;
&lt;td&gt; 2 &lt;/td&gt;
&lt;/tr&gt;
&lt;/table&gt;
</pre><p>
but not the following:
</p>
<pre class="wiki">&lt;table&gt;
&lt;tr&gt;
&lt;td&gt; 1 &lt;/td&gt;
&lt;td&gt; 2 &lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;/table&gt;
</pre>Resultshttps://code.djangoproject.com/ticket/9173#changeloghttps://code.djangoproject.com/ticket/9198
https://code.djangoproject.com/ticket/9198#9198: Make the {% include %} strip a trailing newlineWed, 24 Sep 2008 14:03:37 GMTJavier de la Rosa<p>
If I have a template
</p>
<pre class="wiki"># template1.html
Line 1
Line 2
</pre><p>
And I include this template in other one using templatetag include:
</p>
<pre class="wiki"># template2.html
{% include template1.html %}
Line 3
</pre><p>
The output must be:
</p>
<pre class="wiki"># template2.html
# template1.html
Line 1
Line 2
Line 3
</pre><p>
But the actual output is:
</p>
<pre class="wiki"># template2.html
# template1.html
Line 1
Line 2
Line 3
</pre><p>
This behavior is particularly annoying when it renders a template including JSON.
</p>
Resultshttps://code.djangoproject.com/ticket/9198#changeloghttps://code.djangoproject.com/ticket/9357
https://code.djangoproject.com/ticket/9357#9357: Unable to subclass form Media classMon, 13 Oct 2008 17:05:06 GMTJoey Wilhelm<p>
In essence, I'm simply trying to add a new media type to a number of custom widgets. However, I'm finding that I have to re-implement large parts of Media and MediaDefiningClass, and I even have to do the same on large parts of the Form as well. The main reason behind this is that everything is referencing 'Media()' explicitly, overriding my custom classes.
</p>
Resultshttps://code.djangoproject.com/ticket/9357#changeloghttps://code.djangoproject.com/ticket/9373
https://code.djangoproject.com/ticket/9373#9373: "This field is required" error even on empty inlines formsets in the admin model page, when hiding a choice field of a custom form.Wed, 15 Oct 2008 20:41:25 GMTtyrion.mx@…<p>
I have a custom Form for one of my models (in the example SecondModel) that adds one choice field with an initial value.
If I use that model/form as an inline formset and I exclude the extra field using the "fields" attribute of the ModelAdmin, I got "This Field is required" on all the forms of the formset, including those who where left blank. Here a simple example:
</p>
<div class="wiki-code"><div class="code"><pre><span class="c1"># models.py</span>
<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">FirstModel</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
a <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>max_length<span class="o">=</span><span class="mi">10</span><span class="p">)</span>
b <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>max_length<span class="o">=</span><span class="mi">10</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">SecondModel</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
link <span class="o">=</span> models<span class="o">.</span>ForeignKey<span class="p">(</span>FirstModel<span class="p">)</span>
c <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>max_length<span class="o">=</span><span class="mi">10</span><span class="p">)</span>
<span class="c1"># admin.py</span>
<span class="kn">from</span> <span class="nn">django.contrib</span> <span class="kn">import</span> admin
<span class="kn">from</span> <span class="nn">bug.bugged</span> <span class="kn">import</span> models<span class="p">,</span> forms
<span class="k">class</span> <span class="nc">SecondAdmin</span><span class="p">(</span>admin<span class="o">.</span>TabularInline<span class="p">):</span>
model <span class="o">=</span> models<span class="o">.</span>SecondModel
form <span class="o">=</span> forms<span class="o">.</span>SecondForm
fields <span class="o">=</span> <span class="p">[</span><span class="s1">'c'</span><span class="p">]</span>
extra <span class="o">=</span> <span class="mi">3</span>
<span class="k">class</span> <span class="nc">FirstAdmin</span><span class="p">(</span>admin<span class="o">.</span>ModelAdmin<span class="p">):</span>
inlines <span class="o">=</span> <span class="p">[</span>SecondAdmin<span class="p">]</span>
admin<span class="o">.</span>site<span class="o">.</span>register<span class="p">(</span>models<span class="o">.</span>FirstModel<span class="p">,</span> FirstAdmin<span class="p">)</span>
<span class="c1"># forms.py</span>
<span class="kn">from</span> <span class="nn">django</span> <span class="kn">import</span> forms
<span class="kn">from</span> <span class="nn">bug.bugged</span> <span class="kn">import</span> models
DUMMY_CHOICES <span class="o">=</span> <span class="p">(</span>
<span class="p">(</span><span class="mi">0</span><span class="p">,</span> <span class="s1">'a'</span><span class="p">),</span>
<span class="p">(</span><span class="mi">1</span><span class="p">,</span> <span class="s1">'b'</span><span class="p">),</span>
<span class="p">(</span><span class="mi">2</span><span class="p">,</span> <span class="s1">'c'</span><span class="p">)</span>
<span class="p">)</span>
<span class="k">class</span> <span class="nc">SecondForm</span><span class="p">(</span>forms<span class="o">.</span>ModelForm<span class="p">):</span>
d <span class="o">=</span> forms<span class="o">.</span>IntegerField<span class="p">(</span>label<span class="o">=</span><span class="s1">'d'</span><span class="p">,</span> initial<span class="o">=</span><span class="mi">0</span><span class="p">,</span> widget<span class="o">=</span>forms<span class="o">.</span>Select<span class="p">(</span>choices<span class="o">=</span>DUMMY_CHOICES<span class="p">))</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
model <span class="o">=</span> models<span class="o">.</span>SecondModel
</pre></div></div><p>
The problem is <code>fields = ['c']</code>, commenting out that line I get no errors.
I guess, this is beacuse of the <code>has_changed</code> check, called by the <code>full_clean</code> method of <code>forms.Form</code>. It happens that <code>changed_data</code> compares the initial "d" value that had been set to 0 with the result of "field.widget.value_from_datadict(self.data,..." that is None because we have not a key for "d" in self.data. So changed_data will contain "d" even if the form has not been changed.
</p>
<p>
From django/forms/forms.py
</p>
<div class="wiki-code"><div class="code"><pre> prefixed_name <span class="o">=</span> <span class="bp">self</span><span class="o">.</span>add_prefix<span class="p">(</span>name<span class="p">)</span>
data_value <span class="o">=</span> field<span class="o">.</span>widget<span class="o">.</span>value_from_datadict<span class="p">(</span><span class="bp">self</span><span class="o">.</span>data<span class="p">,</span> <span class="bp">self</span><span class="o">.</span>files<span class="p">,</span> prefixed_name<span class="p">)</span>
<span class="k">if</span> <span class="ow">not</span> field<span class="o">.</span>show_hidden_initial<span class="p">:</span>
initial_value <span class="o">=</span> <span class="bp">self</span><span class="o">.</span>initial<span class="o">.</span>get<span class="p">(</span>name<span class="p">,</span> field<span class="o">.</span>initial<span class="p">)</span>
</pre></div></div>Resultshttps://code.djangoproject.com/ticket/9373#changeloghttps://code.djangoproject.com/ticket/9475
https://code.djangoproject.com/ticket/9475#9475: add(), create(), etc. should be supported by intermediate ManyToMany model with extra attributes if extra fields can be calculatedThu, 30 Oct 2008 11:29:57 GMTomat@…<p>
Intermedite ManyToMany model with extra attributes should support add(), create(), etc. when the extra fields have default values or are calculated.
</p>
<p>
For example, for the following models:
</p>
<pre class="wiki">class Person(models.Model):
name = models.CharField(max_length=128)
class Group(models.Model):
name = models.CharField(max_length=128)
members = models.ManyToManyField(Person, through='Membership')
class Membership(models.Model):
person = models.ForeignKey(Person)
group = models.ForeignKey(Group)
added = models.DateField(auto_now_add=True)
</pre><p>
This should be possible:
</p>
<pre class="wiki">Group.members.add(Person.objects.create(name='Joe'))
</pre><p>
Similarly, if the attributes are calculated in the custom save() method or if they have a default value, those methods should be supported.
</p>
<p>
Maybe, simply removing the extra checks will do. So is it is the values are not sufficient, a db error will be raised anyway.
</p>
Resultshttps://code.djangoproject.com/ticket/9475#changeloghttps://code.djangoproject.com/ticket/9519
https://code.djangoproject.com/ticket/9519#9519: Add QuerySet.bulk_delete() that issues only a single SQL queryTue, 04 Nov 2008 19:53:07 GMTJoey Wilhelm<p>
Example:
</p>
<div class="wiki-code"><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">MyModel</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
my_id <span class="o">=</span> models<span class="o">.</span>IntegerField<span class="p">(</span>primary_key<span class="o">=</span><span class="bp">True</span><span class="p">)</span>
col1 <span class="o">=</span> models<span class="o">.</span>IntegerField<span class="p">()</span>
col2 <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>max_length<span class="o">=</span><span class="mi">1</span><span class="p">)</span>
col3 <span class="o">=</span> models<span class="o">.</span>TextField<span class="p">()</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
unique_together <span class="o">=</span> <span class="p">(</span><span class="s1">'my_id'</span><span class="p">,</span> <span class="s1">'col1'</span><span class="p">,</span> <span class="s1">'col2'</span><span class="p">)</span> <span class="c1"># "Fake" a multi-part primary key</span>
<span class="c1"># This works for creating all 3, as force_insert is used in create()</span>
MyModel<span class="o">.</span>objects<span class="o">.</span>create<span class="p">(</span>my_id<span class="o">=</span><span class="mi">1</span><span class="p">,</span> col1<span class="o">=</span><span class="mi">5</span><span class="p">,</span> col2<span class="o">=</span><span class="s1">'a'</span><span class="p">,</span> col3<span class="o">=</span><span class="s1">'foo'</span><span class="p">)</span>
MyModel<span class="o">.</span>objects<span class="o">.</span>create<span class="p">(</span>my_id<span class="o">=</span><span class="mi">1</span><span class="p">,</span> col1<span class="o">=</span><span class="mi">5</span><span class="p">,</span> col2<span class="o">=</span><span class="s1">'b'</span><span class="p">,</span> col3<span class="o">=</span><span class="s1">'bar'</span><span class="p">)</span>
MyModel<span class="o">.</span>objects<span class="o">.</span>create<span class="p">(</span>my_id<span class="o">=</span><span class="mi">1</span><span class="p">,</span> col1<span class="o">=</span><span class="mi">10</span><span class="p">,</span> col2<span class="o">=</span><span class="s1">'a'</span><span class="p">,</span> col3<span class="o">=</span><span class="s1">'baz'</span><span class="p">)</span>
MyModel<span class="o">.</span>objects<span class="o">.</span>filter<span class="p">(</span>my_id<span class="o">=</span><span class="mi">1</span><span class="p">,</span> col1<span class="o">=</span><span class="mi">5</span><span class="p">)</span><span class="o">.</span>delete<span class="p">()</span>
</pre></div></div><p>
This deletes all of the objects created above, since deletion is done only based on model._meta.pk. This is fine, except when you are using multi-part primary keys and emulating that pkey as suggested in <a class="assigned ticket" href="https://code.djangoproject.com/ticket/373" title="#373: New feature: Add support for multiple-column primary keys (assigned)">#373</a>.
</p>
<p>
In my opinion, the delete operation should be executed with respect to the filter(), extra(), etc which were previously performed on the QuerySet.
</p>
<p>
This is, in a way, a part of ticket <a class="assigned ticket" href="https://code.djangoproject.com/ticket/373" title="#373: New feature: Add support for multiple-column primary keys (assigned)">#373</a>, but I believe it can be viewed as a completely separate issue. In some cases, you do want to delete based on columns other than the primary key. Why build a list of all of those primary keys when you've already specified all of the qualifiers in a filter()?
</p>
Resultshttps://code.djangoproject.com/ticket/9519#changeloghttps://code.djangoproject.com/ticket/9602
https://code.djangoproject.com/ticket/9602#9602: Add admin.site._registry manipulation methodsFri, 14 Nov 2008 19:23:15 GMTRob Hudson<p>
This is a feature request...
</p>
<p>
Currently, one can unregister a model from the admin and register it again with a new ModelAdmin. The problem I'm anticipating is when 2 or more apps want to add ModelAdmin options to a Model and the last one wins.
</p>
<p>
Not to point out a specific 3rd party app, but this is an easily contrived example... If I have my own apps and one of them unregisters the User model's ModelAdmin and registers its own that, say, adds the <code>is_superuser</code> to the list_display. Then if I add the django-openid app that (currently) also unregisters the User model's ModelAdmin and registers its own that adds an inline to a ManyToManyField for the OpenID associations tied to that user. If django-openid is after my app in the INSTALLED_APPS list, I lose my list_display override. And if my app is after the django-openid app, I lose the OpenID associations inlines. (See: <a class="ext-link" href="http://code.google.com/p/django-openid/source/browse/trunk/django_openid/admin.py"><span class="icon">​</span>http://code.google.com/p/django-openid/source/browse/trunk/django_openid/admin.py</a>)
</p>
<p>
It's possible currently to write the unregistration/registration such that this doesn't happen, but it relies on pulling the ModelAdmin out of the "private" _registry dictionary in the admin.site class. For example:
</p>
<pre class="wiki">useradmin = admin.site._registry.get(User, None)
if useradmin:
useradmin.list_display = useradmin.list_display + ('is_superuser',)
else:
class MyUserAdmin(AuthUserAdmin):
list_display = ('username', 'email', 'first_name', 'last_name', 'is_staff', 'is_superuser')
admin.site.register(User, MyUserAdmin)
</pre><p>
I can think of a few ways of fixing this, from least involved to more involved:
</p>
<ol><li>At the very least I think it would be nice if the internal <code>_registry</code> dictionary didn't have the prepended underscore to signify that it is a private variable not to be touched, so one doesn't feel dirty doing something like this.
</li></ol><ol start="2"><li>I think it would be a bit cleaner if there were methods to lookup, get, and update this dict and keep it as a private dict. For example, something like <code>admin.site.get_model_admin(User)</code>?
</li></ol><ol start="3"><li>Along with 2, provide methods to update common ModelAdmin options, like <code>list_display</code>. This one is definitely venturing into debatable area, but something like <code>useradmin.list_display.add('is_superuser')</code> takes much away from this feeling so "monkey patchy".
</li></ol>Resultshttps://code.djangoproject.com/ticket/9602#changeloghttps://code.djangoproject.com/ticket/9631
https://code.djangoproject.com/ticket/9631#9631: FieldFile assumes efficient Storage.sizeWed, 19 Nov 2008 06:20:05 GMTPeter Sagerson<p>
FieldFile's _get_size, like many of its methods, passes the operation on to its Storage object. However, in this case, assuming that a storage mechanism can easily discover the size of a file by name is rather rash. If the file is compressed, for instance, it may be necessary to decompress the entire file to determine the size. Remote storage could suffer from similar issues.
</p>
<p>
Fortunately, FieldFile has a File object provided by the storage. The Storage derivative is responsible for returning a valid File object, which means it must be able to correctly report its size. By asking the File object for its size directly, we provide opportunities for caching so that a size request followed by a read operation need not trigger two independent retrievals of the data.
</p>
Resultshttps://code.djangoproject.com/ticket/9631#changeloghttps://code.djangoproject.com/ticket/9682
https://code.djangoproject.com/ticket/9682#9682: icontains can be case-sensitive on MySQLMon, 24 Nov 2008 18:51:32 GMTto.roma.from.djbug@…<p>
Firstly, this is a known problem, see groups.google.com/group/django-users/browse_thread/thread/2936ad3387c4b369.
</p>
<p>
Secondly, I disagree with the ‘You set the database collation and Django respects that’ approach shown there. For icontains and MySQL, Django generates ‘x LIKE '%y%'’. So, the programmer has told Django explicitly, ‘I want case-insensitive comparison’, and Django tells MySQL, ‘We want default comparison’. This is not field_icontains but rather some field_<em>usingdefaultsettings</em>contains.
</p>
<p>
In fact, here’s how Django defines operators for the MySQL backend:
</p>
<pre class="wiki"> operators = {
'exact': '= %s',
'iexact': 'LIKE %s',
'contains': 'LIKE BINARY %s',
'icontains': 'LIKE %s',
'regex': 'REGEXP BINARY %s',
'iregex': 'REGEXP %s',
'gt': '&gt; %s',
'gte': '&gt;= %s',
'lt': '&lt; %s',
'lte': '&lt;= %s',
'startswith': 'LIKE BINARY %s',
'endswith': 'LIKE BINARY %s',
'istartswith': 'LIKE %s',
'iendswith': 'LIKE %s',
}
</pre><p>
So, case-sensitivity is explicitly requested, while case-insensitivity is implied.
</p>
<p>
The aforementioned thread says that ‘case-sensitive matching with the default utf_*_ci collations’ and overall making ‘things like that work regardless of collation’ is ‘really, really hard’. That sounds strange, because case-sensitive matching is no harder than a simple memcpy, it’s case-insensitive matching that is problematic.
</p>
<p>
However, MySQL doesn’t seem to implement the Unicode collation trickery correctly. It thinks that 'ı' is LIKE 'i' and 'groß' is not LIKE 'GROSS'. (It does perform LOWER('COMMITTED' COLLATE utf8_turkish_ci) correctly, however.) What about altering the above table, making it 'COLLATE utf8_general_ci LIKE %s' for cases where the default collation isn’t case-insensitive?
</p>
<p>
You’re right Unicode is quite hard to implement properly. However, for something_icontains the database does have to determine some collation, and if the default collation is case insensitive, some fallback has to be derived. Maybe the most reasonable solution would be a setting like FORCE_COLLATION_FOR_CI (maybe MySQL-specific, maybe it can be usable for other DBMSs), that would determine how to collate values for which no collation is specified?
</p>
<p>
It would solve a practical problem: I want iexact to differ from exact and icontains to differ from contains (please note these completely reasonable requirements <em>conflict</em> on current MySQL under current Django implementation <em>regardless</em> of collation settings). I’ve read what Django documentation has to say about collation, and while you might be justified in having ‘exact’ return what the database considers exact (for example, for purposes of UNIQUE indices), it’s wrong not to provide a lookup option that would consistently test for case-sensitive equality across DBMSs. Maybe in addition to contains and icontains something like scontains is also needed?
</p>
<hr />
<p>
To summarize, I propose two things:
</p>
<ol><li>For those who have case-insensitive collation in MySQL: a lookup option that would always invoke case-sensitive matching. Maybe the ‘s’ prefix for ‘sensitive’, or ‘b’ for binary: bcontains, bexact, bregex and so on.
</li></ol><ol start="2"><li>For case-sensitive people: an option to set a collation for case-insensitive matches, for example in the settings module.
</li></ol><p>
Both options preserve backwards compatibility and both should be easy to implement. (People on KDE bugzilla have told me I should never tell them whether I think something is easy to implement, but nevertheless it’s a couple of lines for both changes. :-)
</p>
Resultshttps://code.djangoproject.com/ticket/9682#changeloghttps://code.djangoproject.com/ticket/9757
https://code.djangoproject.com/ticket/9757#9757: Make IfNode a baseclass for other if nodes to subclassThu, 04 Dec 2008 17:50:47 GMTAlex Gaynor<p>
Right now any other <code>if</code> type node that wants to exist needs to re-implement all the rendering logic of the if tag, in addition to the conditional it wants to use. To simplify this we could make IfNode do all of the logic to determine whether it evalueates true or not into a seperate method, and then subclasses could just overide the <span class="underline">init</span> and that mehtod.
</p>
Resultshttps://code.djangoproject.com/ticket/9757#changeloghttps://code.djangoproject.com/ticket/9982
https://code.djangoproject.com/ticket/9982#9982: Inconsistent behavior on model save depending on whether OneToOneField is a primary keyWed, 07 Jan 2009 13:14:50 GMTsean@…<p>
Hi,
When using a OneToOneField to make one model extend another, I noticed a behavioral inconsistency depending on whether the related model's OneToOneField was also the primary key or not.
</p>
<p>
The inconsistency is to do with when save() can be called on model instances.
Consider the following example models:
</p>
<pre class="wiki">class BaseModel(models.Model):
pass
class ExtendedModel(models.Model):
link = models.OneToOneField(BaseModel)
</pre><p>
It is not possible to first instantiate these models and later on save them - an <a class="wiki" href="https://code.djangoproject.com/wiki/IntegrityError">IntegrityError</a> would be raised when saving the ExtendedModel. E.g.,
</p>
<pre class="wiki">o1 = BaseModel()
o2 = ExtendedModel(link=o1)
o1.save()
o2.save()
</pre><p>
when o2 is saved it will raise an <a class="wiki" href="https://code.djangoproject.com/wiki/IntegrityError">IntegrityError</a> because it doesn't have a value for the primary key of the model it is related to. I think o1's primary key is copied when o2 is initialized, and is None at this point because o1 isn't saved yet.
</p>
<p>
However, if the definition of ExtendedModel is changed so that the OneToOneField is also the primary key, it now becomes possible to save the model instances in this order. To test this I changed the model definition as follows:
</p>
<pre class="wiki">class ExtendedModel(models.Model):
link = models.OneToOneField(BaseModel, primary_key=True)
</pre><p>
When using this model definition it seems that o1's primary key is copied when o2 is saved, as opposed to when o2 is initialized. This inconsistency caused a lot of head scratching here.
</p>
<p>
Thanks!
Sean
</p>
Resultshttps://code.djangoproject.com/ticket/9982#changeloghttps://code.djangoproject.com/ticket/10060
https://code.djangoproject.com/ticket/10060#10060: Multiple table annotation failureSun, 18 Jan 2009 06:44:38 GMTsvsharma@…<p>
Annotating across multiple tables results in wrong answers. i.e.
</p>
<pre class="wiki">In [110]: total = Branch.objects.all().annotate(total=Sum('center__client__loan__amount'))
In [111]: total[0].total
Out[111]: 3433000
In [112]: repaid = Branch.objects.all().annotate(repaid=Sum('center__client__loan__payment_schedule__payments__principal'))
In [113]: repaid[0].repaid
Out[113]: 1976320.0
In [114]: both = Branch.objects.all().annotate(total=Sum('center__client__loan__amount'),repaid=Sum('center__client__loan__payment_schedule__payments__principal'))
In [115]: both[0].repaid
Out[115]: 1976320.0
In [116]: both[0].total
Out[116]: 98816000
^^^^^^^^^^^
</pre><p>
Compare the output of total in 116 vs. 111 (the correct answer).
</p>
Resultshttps://code.djangoproject.com/ticket/10060#changeloghttps://code.djangoproject.com/ticket/10070
https://code.djangoproject.com/ticket/10070#10070: Named parameters not working on raw sql queries with sqliteMon, 19 Jan 2009 19:41:46 GMTMatias Surdi<p>
The following code shows the problem when using sqlite:
</p>
<pre class="wiki">$ python manage.py shell
Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
&gt;&gt;&gt; from django.db import connection
&gt;&gt;&gt; c = connection.cursor()
&gt;&gt;&gt; c.execute("select name from inventory_host where id=%(id)s",{'id':'1'})
Traceback (most recent call last):
File "&lt;console&gt;", line 1, in &lt;module&gt;
File "/usr/lib/python2.5/site-packages/django/db/backends/util.py", line 19, in execute
return self.cursor.execute(sql, params)
File "/usr/lib/python2.5/site-packages/django/db/backends/sqlite3/base.py", line 167, in execute
query = self.convert_query(query, len(params))
File "/usr/lib/python2.5/site-packages/django/db/backends/sqlite3/base.py", line 179, in convert_query
return query % tuple("?" * num_params)
TypeError: format requires a mapping
&gt;&gt;&gt;
&gt;&gt;&gt; import django
&gt;&gt;&gt; django.VERSION
(1, 0, 2, 'final', 0)
</pre><pre class="wiki">$ sqlite3 --version
3.5.9
</pre><p>
When using Mysql or Postgres, that works (not tested by me, but by others on django-users).
</p>
Resultshttps://code.djangoproject.com/ticket/10070#changeloghttps://code.djangoproject.com/ticket/10088
https://code.djangoproject.com/ticket/10088#10088: for_share() as well as for_update() addition to Model.QuerySetWed, 21 Jan 2009 22:12:38 GMTepandurski<p>
Ticket <a class="closed ticket" href="https://code.djangoproject.com/ticket/2705" title="#2705: New feature: [patch] Add optional FOR UPDATE clause to QuerySets (closed: fixed)">#2705</a> is a very good idea I think.
</p>
<p>
PostgreSQL supports SELECT ... FOR SHARE locking mode, which is basically
the same as FOR UPDATE mode but it does not conflicts with other transaction
having obtained FOR SHARE mode for the row.
(see <a class="ext-link" href="http://www.postgresql.org/docs/8.3/static/sql-select.html#SQL-FOR-UPDATE-SHARE"><span class="icon">​</span>http://www.postgresql.org/docs/8.3/static/sql-select.html#SQL-FOR-UPDATE-SHARE</a>)
It very useful if you need to be sure that your selected rows are not
modified since you have read them (which is true for almost every complex transaction).
</p>
<p>
I am not sure if MySQL has this feature but in PostgreSQL it first-class citizen so
I believe for_share() and for_update() has to be implemented together.
</p>
Resultshttps://code.djangoproject.com/ticket/10088#changeloghttps://code.djangoproject.com/ticket/10227
https://code.djangoproject.com/ticket/10227#10227: Support a related_default on OneToOne fieldsTue, 10 Feb 2009 17:40:21 GMTrvdrijst<p>
EDIT: scroll to comment 13 to see what this ticket is about.
</p>
<p>
Referencing a <code>OneToOneField</code> with <code>null=True</code> (i.e. it's optional) when there is no value set will return <code>None</code>, as expected.
However, referencing the reverse side of the relation does not follow this behavior and raises a <code>DoesNotExist</code> exception.
</p>
<p>
For example, in the following situation where <code>Shop</code>s have optionally a <code>Place</code> (e.g. webshops need not have a physical location):
</p>
<pre class="wiki">class Place(models.Model)
address = models.CharField(max_length=80)
class Shop(models.Model)
place = models.OneToOneField(Place, null=True)
name = models.CharField(max_length=50)
website = models.URLField()
</pre><p>
This <em>does</em> work as expected:
</p>
<pre class="wiki">&gt;&gt;&gt; s1 = Shop.objects.create(name='Shop', website='shop.com')
&gt;&gt;&gt; print s1.place
None
</pre><p>
But this <em>doesn't</em> work as expected:
</p>
<pre class="wiki">&gt;&gt;&gt; p1 = Place.objects.create(address='123 somestr')
&gt;&gt;&gt; p1.shop
... [exception stack trace] ...
DoesNotExist: Shop matching query does not exist.
</pre><p>
I would expect this to be <code>None</code> when <code>null</code> is allowed on the <code>OneToOneField</code>.
</p>
<p>
Please correct my if I'm wrong.
</p>
<p>
I have attached a patch to fix this (checking if <code>null</code> is allowed and returning <code>None</code> or raising the exception appropriately), including tests.
</p>
<p>
Unfortunately this is slightly backwards incompatible, since someone may currently rely on the exception being thrown.
</p>
Resultshttps://code.djangoproject.com/ticket/10227#changeloghttps://code.djangoproject.com/ticket/10244
https://code.djangoproject.com/ticket/10244#10244: FileFields can't be set to NULL in the dbThu, 12 Feb 2009 14:40:54 GMToyvind<p>
Saving FileFields with a none value sets the field to a empty string in the db and not NULL as it should.
</p>
Resultshttps://code.djangoproject.com/ticket/10244#changeloghttps://code.djangoproject.com/ticket/10305
https://code.djangoproject.com/ticket/10305#10305: Add a form instantiation hook for contrib.admin add/change viewsThu, 19 Feb 2009 19:55:56 GMTtangc<p>
<code>add_view</code> and <code>change_view</code> have the following code:
</p>
<div class="wiki-code"><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></div><p>
or:
</p>
<div class="wiki-code"><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></div><p>
or:
</p>
<div class="wiki-code"><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></div><p>
I would propose:
</p>
<div class="wiki-code"><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></div><p>
This way gives the flexibility to override the function <code>get_form(self, request, obj=None, **kwargs)</code>, which could return a <code>modelform_factory(self.model, **defaults)</code> 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/10621
https://code.djangoproject.com/ticket/10621#10621: Add a way to have an aggregate() result as a querysetWed, 25 Mar 2009 09:35:49 GMTMalcolm Tredinnick<p>
If one is trying to construct a complex queryset, involving nesting other querysets, there's currently no way to include the results of an <code>aggregate()</code> call. For example, consider
</p>
<div class="wiki-code"><div class="code"><pre><span class="k">class</span> <span class="nc">Item</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">10</span><span class="p">)</span>
</pre></div></div><p>
If I want to include the number of Items in some other queryset, such as
</p>
<div class="wiki-code"><div class="code"><pre>Foo<span class="o">.</span>objects<span class="o">.</span>filter<span class="p">(</span>items__in<span class="o">=</span><span class="p">[</span><span class="o">...</span><span class="p">])</span><span class="o">.</span>annotate<span class="p">(</span>num<span class="o">=</span>Count<span class="p">(</span><span class="s2">"items"</span><span class="p">)</span><span class="o">.</span>filter<span class="p">(</span>num<span class="o">=</span>item_count<span class="p">)</span>
</pre></div></div><p>
We can't write item_count (which would be <code>Items.objects.aggregate(Count("id"))</code>) as an inner queryset here, since the <code>aggregate()</code> call returns a dictionary, not a queryset.
</p>
<p>
The return value of <code>aggregate()</code> is fine, but this ticket is about adding a version that does return a queryset. Right now, there's no way to fake this with <code>annotate(...).values(...)</code> since that always introduces a <code>GROUP BY</code> clause and the whole point is not to group by anything.
</p>
<p>
Not sure whether adding a parameter to <code>aggregate()</code> is the right idea, or adding something to the <code>annotate()</code> route to specify "no grouping whatsoever". This is all 1.2 timeframe stuff, but it's something to think about.
</p>
Resultshttps://code.djangoproject.com/ticket/10621#changeloghttps://code.djangoproject.com/ticket/10743
https://code.djangoproject.com/ticket/10743#10743: Support lookup separators in ModelAdmin.list_displaySun, 05 Apr 2009 23:08:42 GMTmrts<p>
As with <a class="closed ticket" href="https://code.djangoproject.com/ticket/3400" title="#3400: Support for lookup separator with list_filter admin option (closed: fixed)">#3400</a>, supporting the <code>__</code> lookup separator in <code>ModelAdmin.list_display</code> is useful as it avoids calling <code>__unicode__</code> bluntly, giving users more control over the output:
</p>
<ul><li>display several fields from the same related model,
</li><li>as listed in <a class="closed ticket" href="https://code.djangoproject.com/ticket/3400" title="#3400: Support for lookup separator with list_filter admin option (closed: fixed)">#3400</a>, traverse several levels of relations.
</li></ul><p>
One could argue that most of this can be achieved with <code>__unicode__</code> by cramming the information to its output.
</p>
<p>
However, there's a larger problem with deferred fields (deferring is exemplified in <a class="ext-link" href="http://code.djangoproject.com/ticket/10712#comment:3"><span class="icon">​</span>this comment</a>) -- namely, that couples admin code to the implementation of <code>__unicode__</code> in related models. That is, knowledge of what fields are referred to in <code>__unicode__</code> is required to write proper deferred statements.
</p>
<p>
A case to illustrate how changes in <code>__unicode__</code> can have dramatic, unintentional impact:
</p>
<ul><li>assume the related objects are large and complex,
</li><li>to keep the admin changelist view snappy, the developer looks which fields are referred to in their <code>__unicode__</code> and writes the <code>ModelAdmin.queryset()</code> method correspondingly, selecting only these fields with <code>only()</code>,
</li><li>a single query is all that is needed to display the data in changelist view, admin is snappy, there is much rejoicing,
</li><li>a second person keeps hacking at the related models, unknowing the impact changes to <code>__unicode__</code> could have to admin, adds another field to it,
</li><li>suddenly rendering the changelist results in <code>n</code> queries, each of which pulls in the whole object.
</li></ul><p>
All that can be avoided with explicit <code>__</code> support.
</p>
Resultshttps://code.djangoproject.com/ticket/10743#changeloghttps://code.djangoproject.com/ticket/10761
https://code.djangoproject.com/ticket/10761#10761: ModelAdmin.queryset() is missing a mechanism for specifying different querysets for changelist and change object viewsTue, 07 Apr 2009 21:12:10 GMTmrts<p>
<code>ModelAdmin.queryset()</code> is used both in the changelist and change object views.
</p>
<p>
Suppose some fields are deferred in the returned queryset to speed up changelist rendering. As a result, the object change view has to perform additional queries for all the deferred fields to pull them in.
</p>
<p>
The proposed solution is to add another parameter to <code>queryset()</code> that specifies whether a changelist or change object queryset should be returned as follows:
</p>
<pre class="wiki">def queryset(self, request, for_change_object_view=False):
</pre>Resultshttps://code.djangoproject.com/ticket/10761#changeloghttps://code.djangoproject.com/ticket/10827
https://code.djangoproject.com/ticket/10827#10827: django.auth create_permissions must clear the content type cache before creating permissionsWed, 15 Apr 2009 21:39:56 GMTSean Legassick<p>
I hit a problem which took some time to track down, where at the DB flush stage in a sequence of tests (using TransactionTestCase) the recreation of permissions was failing with a FK constraint error.
</p>
<p>
This was caused by inserting a permission referring to a content type that didn't exist in the DB.
</p>
<p>
This happened because the content type was still in the cache, even thought the django_content_type table had been truncated.
</p>
<p>
The cache hadn't been cleared because post_syncdb signal dispatch had called create_permissions before calling update_contenttypes (which does clear the cache and recreate the content types correctly).
</p>
<p>
The real problem here is that create_permissions and update_contenttypes are both connected to the post_syncdb signal, with the former depending on the latter having been run first, but the dispatcher doesn't guarantee order of dispatch (or rather it dispatches in the order the signal handlers are connected, but that order depends on the order in which modules are loading which is not well-defined). Unfortunately that's a hard problem to solve, and I don't have any ideas about that short of substantive changes to the signal dispatcher.
</p>
<p>
An easier solution to this particular problem is for create_permissions to clear the content types cache before it recreates permissions, that way the necesarry content types will be created as needed (see attached patch).
</p>
Resultshttps://code.djangoproject.com/ticket/10827#changeloghttps://code.djangoproject.com/ticket/10850
https://code.djangoproject.com/ticket/10850#10850: Impossible to stop a large file upload mid-streamFri, 17 Apr 2009 06:38:01 GMTlegutierr<p>
As described in <a class="ext-link" href="http://groups.google.com/group/django-users/browse_thread/thread/d4e4394c1b3d68dc/f8bc012acf797219?lnk=gst&amp;q=StopUpload#f8bc012acf797219"><span class="icon">​</span>this post</a> on the django-users group, raising <code>django.core.files.uploadhandler.StopUpload(connection_reset=True)</code> in order to cut off a too-large file upload does not work <a class="ext-link" href="http://docs.djangoproject.com/en/dev/topics/http/file-uploads/#required-methods"><span class="icon">​</span>as documented</a>. Nor does it work as specified in <a class="ext-link" href="http://code.djangoproject.com/browser/django/trunk/django/core/files/uploadhandler.py#L30"><span class="icon">​</span>comments to the code</a>, nor according to <a class="ext-link" href="http://code.djangoproject.com/ticket/2070#comment:275"><span class="icon">​</span>a discussion</a> regarding the implementation of this feature.
</p>
<p>
The connection reset functionality does work correctly using the development server, but not using mod_python or fastcgi on lighttpd or Apache. It seems that in both cases the webserver pre-loads the entire file, regardless of its size, without Django taking the opportunity to interrupt the stream, even if <code>StopUpload(connection_reset=True)</code> is raised by <code>receive_data_chunk()</code> inside a subclass of <code>FileUploadHandler</code>.
</p>
<p>
The most egregious side effect of this defect is that while the file is uploading to the server, the server experiences significant slow-downs.
</p>
<p>
In addition, without a fix, any restrictions on file-size for upload will not be delivered to users until they have waited for many minutes uploading their unacceptable file, a user-interaction failure that should be avoidable.
</p>
Resultshttps://code.djangoproject.com/ticket/10850#changeloghttps://code.djangoproject.com/ticket/10874
https://code.djangoproject.com/ticket/10874#10874: ModelFormMetaclass does not provide easy way of extendingMon, 20 Apr 2009 09:57:02 GMTwombat<p>
I am currently creating an extension to the ModelForm that provides similar features to Admin such as fieldsets. Unfortunately, the ModelFormMetaclass does not provide easy way of extending ModelForm. For example, I need to access meta information for fieldsets and dynamicaly flatten to fields before method fields_for_model is called. Also, what if I wanted to override fields for model. There is no way of doing this without completely overriting the entire ModelFormMetaclass. It seems that the meta class approach initialization does not support granual overriding of logic. I have made the following code change to django ModelFormMetaclass to ease my pain for now. However, in the long run it may not be enought.
</p>
<pre class="wiki">class ModelFormMetaclass(type):
....
options_class = attrs.pop('options_class', ModelFormOptions)
opts = new_class._meta = options_class(getattr(new_class, 'Meta', None))
...
</pre><p>
The following is the code that uses this:
</p>
<pre class="wiki">
class DynamicModelFormOptions(ModelFormOptions):
def __init__(self, options=None):
super(DynamicModelFormOptions,self).__init__(options)
self.fieldsets = getattr(options, 'fieldsets', None)
self.fieldwidths = getattr(options, 'fieldwidths', None)
if self.fieldsets:
self.fields = flatten_fieldsets(self.fieldsets)
class DynamicModelFormMetaclass(ModelFormMetaclass):
def __new__(cls, name, bases, attrs):
attrs['formfield_callback'] = formfield_for_dbfield
attrs['options_class'] = DynamicModelFormOptions
new_class = super(DynamicModelFormMetaclass, cls).__new__(cls, name, bases,
attrs)
#new_class._meta = DynamicModelFormOptions(getattr(new_class, 'Meta', None))
#assign_default_widgets(new_class.base_fields)
return new_class
</pre>Resultshttps://code.djangoproject.com/ticket/10874#changeloghttps://code.djangoproject.com/ticket/10919
https://code.djangoproject.com/ticket/10919#10919: Add an option to disable display of related items on admin's delete confirmation page (to prevent large memory usage on complex objects)Fri, 24 Apr 2009 16:24:19 GMTTobias McNulty<p>
I recently tried to delete an object in the admin that had several million related objects.
</p>
<p>
The server quickly ran out of memory as the apache process's memory usage ballooned upwards to near a gigabyte.
</p>
<p>
I assume this is because it was trying to create an HTML page listing out all the related objects.
</p>
<p>
Can the admin page do a count and/or limit to avoid this?
</p>
<p>
I'm using Django 1.1 trunk (<a class="changeset" href="https://code.djangoproject.com/changeset/10628/">r10628</a>), mod_wsgi 2.0, and apache 2.2.8.
</p>
Resultshttps://code.djangoproject.com/ticket/10919#changeloghttps://code.djangoproject.com/ticket/10929
https://code.djangoproject.com/ticket/10929#10929: Support a default value for Sum (and possibly other aggregation functions)Sat, 25 Apr 2009 22:16:17 GMTnolan<p>
By default, annotate(sum_field = Sum(...)) results in sum_field being NULL if there were no values to sum. In most cases, 0 would be a better option here, for proper sorting in a later order_by, and for comparisons using lt/gt/gte/lte.
</p>
<p>
A monkeypatch to implement default values for NULL using COALESCE is available here:
<a class="ext-link" href="http://stackoverflow.com/questions/553038/treat-null-as-0-in-django-model"><span class="icon">​</span>http://stackoverflow.com/questions/553038/treat-null-as-0-in-django-model</a>
</p>
Resultshttps://code.djangoproject.com/ticket/10929#changeloghttps://code.djangoproject.com/ticket/10941
https://code.djangoproject.com/ticket/10941#10941: Add a templatetag to generate querystringsTue, 28 Apr 2009 00:57:52 GMTBen Spaulding<p>
Working with pagination and query strings within a template can be painful. Personally, I have never had a situation when I was paginating using a GET parameter where there were not other parameters that needed to be preserved through out the various pages.
</p>
<p>
Take search, for example. There may be parameters for searching within one or more models, for a particular author and sorting by date. Maintaining all of these parameters within the pagination links takes some serious template logic.
</p>
<pre class="wiki">{# Linebreaks added for readability. In real life this would need to be one, long line. #}
&lt;a href="?{% for key, values in request.GET.iterlists %}
{% ifnotequal key "page" %}
{% for value in values %}
{{ key }}={{ value }}&amp;amp;
{% endfor %}
{% endifnotequal %}
{% endfor %}page={{ page.next_page_number }}"&gt;Next page&lt;/a&gt;
</pre><p>
That kind of logic shouldn’t be in a template. I have created a patch that would allow for something much simpler, like so:
</p>
<pre class="wiki">&lt;a href="?{{ page.next_page_querystring }}"&gt;Next page&lt;/a&gt;
</pre><p>
Though there has been much talk of creating template tags which would produce all-out pagination bars, I believe this particular functionality should be an actual method on the page object for two reasons:
</p>
<ol><li>This is basic functionality whose end result is hard to dispute (as opposed to a full pagination bar where markup and features could be disputed eternally),
</li><li>This does not require the request context processor to be installed.
</li></ol><p>
Note that this patch includes documentation. Tests are still needed. I am not married to the exact implementation, but I and others I have discussed this and feel that this simplicity and fuctionality belong in Django’s pagination.
</p>
Resultshttps://code.djangoproject.com/ticket/10941#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 GMTTai Lee<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 <code>state</code> is a StateProxy object and I try <code>state.country</code>, I'll end up with a !Country object instead of a CountryProxy object. Likewise if <code>country</code> is a CountryProxy object and I try <code>country.state_set.all()</code>, I'll end up with a queryset of !State objects instead of StateProxy objects.
</p>
<p>
This can be worked around with queries like <code>Country.objects.get(pk=state.country.pk)</code> and <code>State.objects.filter(country=country)</code>, 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/11094
https://code.djangoproject.com/ticket/11094#11094: default_lon and default_lat have no effect for OSMGeoAdminWed, 13 May 2009 13:31:24 GMTstuartk<p>
When using the default_lon and default_lat options with OSMGeoAdmin, no changes are made to the presented map. The options work when using GeoModelAdmin.
</p>
<p>
Using the examples given on the Open Street Map wiki for using OpenLayers, I have created a small patch to the openlayers.js file. I have tested it, and it doesn't effect the use of GeoModelAdmin.
</p>
Resultshttps://code.djangoproject.com/ticket/11094#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 GMTAndriy Drozdyuk<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/11156
https://code.djangoproject.com/ticket/11156#11156: Unnecessary savepoints with OracleWed, 20 May 2009 10:24:55 GMTRichard Davies <richard.davies@…><p>
Savepoints are implemented in the Postgresql and Oracle backends, and provide a useful features to users of both.
</p>
<p>
In addition, the framework itself wraps various calls in savepoints (e.g. inside django/db/models/query.py:get_or_create). This is to work around a Postgresql-specific oddity that the open transaction needs to be rolled back to a prior savepoint if it experiences a database exception.
</p>
<p>
This oddity is not present on Oracle, so the extra savepoints are not required. We probably need to split the current single backend flag uses_savepoints into two: can_savepoint and needs_savepoint_after_exception.
</p>
<p>
See <a class="ext-link" href="http://groups.google.com/group/django-developers/browse_thread/thread/bca33ecf27ff5d63"><span class="icon">​</span>http://groups.google.com/group/django-developers/browse_thread/thread/bca33ecf27ff5d63</a>
</p>
Resultshttps://code.djangoproject.com/ticket/11156#changeloghttps://code.djangoproject.com/ticket/11265
https://code.djangoproject.com/ticket/11265#11265: ForeignKey/OneToOneField should support user-defined id attribute nameFri, 05 Jun 2009 12:03:46 GMTdstora<p>
Currently, when defining a ForeignKey/OneToOneField field XXX, Django automatically defines a XXX_id attribute to store the id value.<br />
However, it is sometimes desirable to decide of the name as XXX_id may not be the most appropriate.
</p>
<hr />
<p>
Let's take the following example:
</p>
<ul><li>I initially have a table "Payment" with a "ccy_code" field designating a 3-letter currency code.
</li></ul><p>
My model definition looks like:
</p>
<pre class="wiki"> from django.db import model
class Payment(models.Model):
# ...
ccy_code = models.CharField(max_length=3)
</pre><p>
In my python code I refer to the currency code as follows:
</p>
<pre class="wiki"> p = Payment()
#...
print p.ccy_code
</pre><ul><li>Later, I decide to actually create a "Currency" table to hold some information about currencies.
</li></ul><p>
And I also decide to define a foreign key constraint from "Payment" to "Currency".
My model now looks like:
</p>
<pre class="wiki"> from django.db import model
class Currency(models.Model):
ccy_code = models.CharField(max_length=3, primary_key=True)
#...
class Payment(models.Model):
# ...
ccy = models.ForeignKey(Currency, to_field="ccy_code", db_column="ccy_code")
</pre><p>
The problem here is that my existing Python code is broken, because "ccy_code" is not defined anymore for "Payment".
Django has instead define a "ccy_id" attribute.
</p>
<hr />
<p>
Based on the principle that defining things like foreign keys should only add functionality (and not remove any) it seems quite important to me that one can choose the id attribute name.<br />
<br />
This can be achieved by adding an optional keyword argument to ForeignKey/OneToOneField constructors (here I decided to call it "id_attr_name").<br />
The implementation of this feature is pretty small and fully backward-compatible.<br />
Here is the SVN diff against trunk:
</p>
<pre class="wiki">Index: related.py
===================================================================
--- related.py (revision 10924)
+++ related.py (working copy)
@@ -660,6 +660,7 @@
class ForeignKey(RelatedField, Field):
empty_strings_allowed = False
def __init__(self, to, to_field=None, rel_class=ManyToOneRel, **kwargs):
+ self.__id_attr_name = kwargs.pop('id_attr_name', None)
try:
to_name = to._meta.object_name.lower()
except AttributeError: # to._meta doesn't exist, so it must be RECURSIVE_RELATIONSHIP_CONSTANT
@@ -679,7 +680,10 @@
self.db_index = True
def get_attname(self):
- return '%s_id' % self.name
+ if self.__id_attr_name:
+ return self.__id_attr_name
+ else:
+ return '%s_id' % self.name
def get_validator_unique_lookup_type(self):
return '%s__%s__exact' % (self.name, self.rel.get_related_field().name)
</pre><p>
In my example, I could then define my model like:
</p>
<pre class="wiki"> from django.db import model
class Currency(models.Model):
ccy_code = models.CharField(max_length=3, primary_key=True)
#...
class Payment(models.Model):
# ...
ccy = models.ForeignKey(Currency, to_field="ccy_code", db_column="ccy_code", id_attr_name="ccy_code")
</pre>Resultshttps://code.djangoproject.com/ticket/11265#changeloghttps://code.djangoproject.com/ticket/11294
https://code.djangoproject.com/ticket/11294#11294: Django administration Model list always shows Decimal with decimal placesWed, 10 Jun 2009 15:36:07 GMTjason@…<p>
Only in the list_display does the admin interface show DecimalField with precision of .00. In the view of an object in the Model, 0.00, for example, would be shown as 0, without the precision. I'd say the same rendering should be for both, and that displaying without the .00 is preferred.
</p>
Resultshttps://code.djangoproject.com/ticket/11294#changeloghttps://code.djangoproject.com/ticket/11383
https://code.djangoproject.com/ticket/11383#11383: Admin action 'Delete selected' check only global model delete permissionFri, 26 Jun 2009 09:03:27 GMTkrejcik@…<p>
Action 'delete_selected' calls ModelAdmin's has_delete_permission method only once without obj argument.
(This action is run from object list with checked records)
It is problem if has_delete_permission contains more complex logic which returns different values for a particular objects.
If one of deleted objects must not be delete whole action should fail.
</p>
<p>
Simple workaround is always forbid global delete (it means return False if obj argument is not given) and allow delete only for specified objects.
But such solutuion still disallow to do multiple delete on objects which can be deleted separately from it's detail form.
</p>
Resultshttps://code.djangoproject.com/ticket/11383#changeloghttps://code.djangoproject.com/ticket/11385
https://code.djangoproject.com/ticket/11385#11385: DateTimeField doesn't accept ISO 8601 formatted date stringFri, 26 Jun 2009 10:17:06 GMTJani Tiainen<p>
DateTimeField doesn't accept ISO 8601 formatted date string. Differene is that ISO format allows date and time separator to be capital T letter. (Format being YYYY-MM-DDTHH:MM:SS. Django expects to have only space as a date and time separator.
</p>
Resultshttps://code.djangoproject.com/ticket/11385#changeloghttps://code.djangoproject.com/ticket/11479
https://code.djangoproject.com/ticket/11479#11479: cache_page and last_modified decorators can't be used togetherTue, 14 Jul 2009 15:28:55 GMTmegaman821@…<p>
The function the calculates the last_modified date will always run but since the cache_page decorator ends up calling a middleware it will get to the last_modified and etag headers first. It will see that they are empty (because only another middleware could have changed them at that point) and then set them to default values. Then the last_modified decorator will see the last modified header is already set and not change it.
</p>
Resultshttps://code.djangoproject.com/ticket/11479#changeloghttps://code.djangoproject.com/ticket/11487
https://code.djangoproject.com/ticket/11487#11487: Oracle encoding bug when saving more than 4000 charactersThu, 16 Jul 2009 15:11:57 GMTMarcos Daniel Petry<p>
I am working on a project where I have to store a large amount of
content, (html) in a record from a table, I am using Oracle as the
database
</p>
<p>
What is very strange ... is put a text reasonably small, (around 3000
characters) and it works correctly, save without problems, but
doubling this size, this content is saved completely changed.
</p>
<p>
This patch works well on: Django 1.1 (svn), debian, and Oracle 10g
with cx_oracle 4.4.1
</p>
Resultshttps://code.djangoproject.com/ticket/11487#changeloghttps://code.djangoproject.com/ticket/11505
https://code.djangoproject.com/ticket/11505#11505: Django's TestCase should reset the cacheSun, 19 Jul 2009 14:49:12 GMTandrewfong<p>
In between test cases, the cache should be flushed in order to prevent one test case from polluting another, similar to how the database is currently flushed (or transactions rolled back) in Django's test case.
</p>
<p>
This will be easier to implement if <a class="closed ticket" href="https://code.djangoproject.com/ticket/11503" title="#11503: Cache backend should expose a flush method (closed: duplicate)">#11503</a> is complete
</p>
Resultshttps://code.djangoproject.com/ticket/11505#changeloghttps://code.djangoproject.com/ticket/11541
https://code.djangoproject.com/ticket/11541#11541: F() expressions don't allow assignment of Foreign Key values on instancesFri, 24 Jul 2009 13:35:44 GMTRussell Keith-Magee<p>
Lines 93-102 of the expressions model test define the following test case:
</p>
<pre class="wiki"># F expressions cannot be used to update attributes which are foreign keys, or
# attributes which involve joins.
&gt;&gt;&gt; test_gmbh.point_of_contact = None
&gt;&gt;&gt; test_gmbh.save()
&gt;&gt;&gt; test_gmbh.point_of_contact is None
True
&gt;&gt;&gt; test_gmbh.point_of_contact = F('ceo')
Traceback (most recent call last):
...
ValueError: Cannot assign "&lt;django.db.models.expressions.F object at ...&gt;": "Company.point_of_contact" must be a "Employee" instance.
</pre><p>
There's no reason this sort of assignment shouldn't be possible - it just requires the appropriate handling on the related field.
</p>
Resultshttps://code.djangoproject.com/ticket/11541#changeloghttps://code.djangoproject.com/ticket/11561
https://code.djangoproject.com/ticket/11561#11561: raw_id_fields requires that the user has change permissions on the model class that is being linked toMon, 27 Jul 2009 09:27:35 GMTdhowden@…<p>
Unlike a plain ForeignKey field which uses a select box, the raw_id_fields listing/search interface requires that the user has change permissions on the model in your ForeignKey.
</p>
Resultshttps://code.djangoproject.com/ticket/11561#changeloghttps://code.djangoproject.com/ticket/11580
https://code.djangoproject.com/ticket/11580#11580: Unable to query TextField against oracle nclob 10Gr4Tue, 28 Jul 2009 19:14:20 GMTMark Anderson<p>
I have tried <span class="underline">icontains and </span>regex against a TextField on an oracle database and get the following error:
</p>
<p>
DatabaseError: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at line 1
</p>
<p>
The code was ported directly over from mysql where the i_contains query worked. The column was created as an NCLOB. I can query against other fields fine.
</p>
<p>
Environment:
</p>
<p>
Request Method: GET
Request URL: <a class="ext-link" href="http://django/eis/banobj/search/?q=class"><span class="icon">​</span>http://django/eis/banobj/search/?q=class</a>
Django Version: 1.1 rc 1 SVN-11348
Python Version: 2.4.3
Installed Applications:
['django.contrib.auth',
</p>
<blockquote>
<p>
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'eis.banobj',
'django.contrib.admin',
'django.contrib.admindocs',
'eis.ldapauth',
'eis.emailLogs']
</p>
</blockquote>
<p>
Installed Middleware:
('django.middleware.common.CommonMiddleware',
</p>
<blockquote>
<p>
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware')
</p>
</blockquote>
<p>
Template error:
In template /opt/django/eis/templates/banobj/arealist.html, error at line 17
</p>
<blockquote>
<p>
Caught an exception while rendering: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
</p>
</blockquote>
<p>
ORA-06512: at line 1
</p>
<blockquote>
<p>
7 : {% block content %}
</p>
</blockquote>
<blockquote>
<p>
8 : &lt;h1&gt; {{heading}} &lt;/h1&gt;
</p>
</blockquote>
<blockquote>
<p>
9 : &lt;table border=1&gt;
</p>
</blockquote>
<blockquote>
<p>
10 : &lt;tr&gt;
</p>
</blockquote>
<blockquote>
<p>
11 : &lt;th&gt;Banner Object&lt;/th&gt;
</p>
</blockquote>
<blockquote>
<p>
12 : &lt;th&gt;Ready For Testing&lt;/th&gt;
</p>
</blockquote>
<blockquote>
<p>
13 : &lt;th&gt;Tested&lt;/th&gt;
</p>
</blockquote>
<blockquote>
<p>
14 : &lt;th&gt;Primary User&lt;/th&gt;
</p>
</blockquote>
<blockquote>
<p>
15 : &lt;th&gt;Object Type&lt;/th&gt;
</p>
</blockquote>
<blockquote>
<p>
16 : &lt;/tr&gt;
</p>
</blockquote>
<blockquote>
<p>
17 : {% for obj in obj_list %}
</p>
</blockquote>
<blockquote>
<p>
18 : &lt;tr bgcolor="{% cycle rowcolors %}"&gt;
</p>
</blockquote>
<blockquote>
<p>
19 : &lt;td&gt;&lt;a href="/eis/banobj/wiki/{{ obj.id }}/"&gt;{{ obj.name|upper }}&lt;/a&gt;&lt;/td&gt;
</p>
</blockquote>
<blockquote>
<p>
20 : &lt;td&gt;{% if obj.prod_svn %}
</p>
</blockquote>
<blockquote>
<p>
21 : &lt;img src="/media/img/admin/icon-yes.gif"&gt;
</p>
</blockquote>
<blockquote>
<p>
22 : {% else %}
</p>
</blockquote>
<blockquote>
<p>
23 : &lt;img src="/media/img/admin/icon-no.gif"&gt;
</p>
</blockquote>
<blockquote>
<p>
24 : {% endif %}&lt;/td&gt;
</p>
</blockquote>
<blockquote>
<p>
25 : &lt;td&gt;{% if obj.user_tested %}
</p>
</blockquote>
<blockquote>
<p>
26 : &lt;img src="/media/img/admin/icon-yes.gif"&gt;
</p>
</blockquote>
<blockquote>
<p>
27 : {% else %}
</p>
</blockquote>
<p>
Traceback:
File "/usr/lib/python2.4/site-packages/django/core/handlers/base.py" in get_response
</p>
<ol start="92"><li> response = callback(request, *callback_args, <strong>callback_kwargs)
</strong></li></ol><p>
File "/usr/lib/python2.4/site-packages/django/contrib/auth/decorators.py" in <span class="underline">call</span>
</p>
<ol start="78"><li> return self.view_func(request, *args, <strong>kwargs)
</strong></li></ol><p>
File "/opt/django/eis/banobj/views.py" in search
</p>
<ol start="172"><li> context_instance=RequestContext(request))
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/shortcuts/<span class="underline">init</span>.py" in render_to_response
</p>
<ol start="20"><li> return HttpResponse(loader.render_to_string(*args, <strong>kwargs), </strong>httpresponse_kwargs)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/loader.py" in render_to_string
</p>
<ol start="108"><li> return t.render(context_instance)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/<span class="underline">init</span>.py" in render
</p>
<ol start="178"><li> return self.nodelist.render(context)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/<span class="underline">init</span>.py" in render
</p>
<ol start="779"><li> bits.append(self.render_node(node, context))
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/debug.py" in render_node
</p>
<ol start="71"><li> result = node.render(context)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/loader_tags.py" in render
</p>
<ol start="97"><li> return compiled_parent.render(context)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/<span class="underline">init</span>.py" in render
</p>
<ol start="178"><li> return self.nodelist.render(context)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/<span class="underline">init</span>.py" in render
</p>
<ol start="779"><li> bits.append(self.render_node(node, context))
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/debug.py" in render_node
</p>
<ol start="71"><li> result = node.render(context)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/loader_tags.py" in render
</p>
<ol start="24"><li> result = self.nodelist.render(context)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/<span class="underline">init</span>.py" in render
</p>
<ol start="779"><li> bits.append(self.render_node(node, context))
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/debug.py" in render_node
</p>
<ol start="81"><li> raise wrapped
</li></ol><p>
Exception Type: TemplateSyntaxError at /banobj/search/
Exception Value: Caught an exception while rendering: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at line 1
</p>
<p>
Original Traceback (most recent call last):
</p>
<blockquote>
<p>
File "/usr/lib/python2.4/site-packages/django/template/debug.py", line 71, in render_node
</p>
<blockquote>
<p>
result = node.render(context)
</p>
</blockquote>
<p>
File "/usr/lib/python2.4/site-packages/django/template/defaulttags.py", line 126, in render
</p>
<blockquote>
<p>
len_values = len(values)
</p>
</blockquote>
<p>
File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 81, in <span class="underline">len</span>
</p>
<blockquote>
<p>
self._result_cache = list(self.iterator())
</p>
</blockquote>
<p>
File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 238, in iterator
</p>
<blockquote>
<p>
for row in self.query.results_iter():
</p>
</blockquote>
<p>
File "/usr/lib/python2.4/site-packages/django/db/models/sql/query.py", line 287, in results_iter
</p>
<blockquote>
<p>
for rows in self.execute_sql(MULTI):
</p>
</blockquote>
<p>
File "/usr/lib/python2.4/site-packages/django/db/models/sql/query.py", line 2383, in &lt;lambda&gt;
</p>
<blockquote>
<p>
result = iter((lambda: cursor.fetchmany(GET_ITERATOR_CHUNK_SIZE)),
</p>
</blockquote>
<p>
File "/usr/lib/python2.4/site-packages/django/db/backends/oracle/base.py", line 469, in fetchmany
</p>
<blockquote>
<p>
return tuple([self._rowfactory(r)
</p>
</blockquote>
</blockquote>
<p>
DatabaseError: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at line 1
</p>
Resultshttps://code.djangoproject.com/ticket/11580#changeloghttps://code.djangoproject.com/ticket/11593
https://code.djangoproject.com/ticket/11593#11593: Incomplete support for app-level testingWed, 29 Jul 2009 19:30:41 GMTMasklinn<p>
Django and its community have a pretty strong focus on the concept of reusable applications: applications as pluggable behavior blocks, independent from one another and from projects. And the test framework documentation and setup emphasize that: the documentation page is called <a class="ext-link" href="http://docs.djangoproject.com/en/dev/topics/testing/"><span class="icon">​</span>Testing Django applications</a> and the test themselves are saved at the application level not at the project level.
</p>
<p>
Yet Django provides no provision whatsoever for running tests from an application: a project (or at least a settings and a urls file) is required, and barring fairly weird setups (global settings and urls modules) there is no way to create a new app, write a test and run it just like that. Which means applications aren't as self-contained as they could be, and can't easily be tested "in a void" (independently of everything else).
</p>
Resultshttps://code.djangoproject.com/ticket/11593#changeloghttps://code.djangoproject.com/ticket/11634
https://code.djangoproject.com/ticket/11634#11634: OpenLayers default positionTue, 04 Aug 2009 20:01:00 GMTMattias Dalkvist<p>
The openlayers.js templet don't take the display projection setting from the GeoModelAdmin classes in to consideration when applying the default position.
</p>
<p>
Fore example then the display projection is sett to 4326 (wgs83 standard lon/lat) and the map projection is sett to 900913 (the "google projection").
Then it is reasonable to expect the default position to be in the display projection and not the map projection.
</p>
<p>
The supplied patch checks to see if the display_projection is sett, if it is then adds a transformation call (from display projection to map projection) when the default position is used, in the openlayers.js
</p>
Resultshttps://code.djangoproject.com/ticket/11634#changeloghttps://code.djangoproject.com/ticket/11760
https://code.djangoproject.com/ticket/11760#11760: Placeholder for through value in ManyToManyField of abstract classFri, 21 Aug 2009 11:42:43 GMTMS<p>
If you have an abstract class with ManyToManyField it is possible to user %(class)s in related_name for generic related name. Same should be possible for through, to define a generic name for through tables.
</p>
<p>
Example:
</p>
<pre class="wiki">class ClassA(models.Model):
...
class AbstractClass(models.Model):
name = models.ManyToManyField(ClassA, related_name = '%(class)s_name', through = 'ClassA_%(class)s')
class MyClass(AbstractClass):
...
Class ClassA_MyClass(models.Model)
class_a=models.ForeignKey(ClassA)
my_class=models.ForeignKey(MyClass)
</pre><p>
The applied patch uses the same mechanism as used for related_name.
</p>
Resultshttps://code.djangoproject.com/ticket/11760#changeloghttps://code.djangoproject.com/ticket/11803
https://code.djangoproject.com/ticket/11803#11803: Admin does not update every ForeignKey select of the same modelSun, 30 Aug 2009 14:18:30 GMTdanilo <danilo.cabello@…><p>
Consider I have the following models:
</p>
<div class="wiki-code"><div class="code"><pre><span class="k">class</span> <span class="nc">City</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><span class="mi">80</span><span class="p">)</span>
state <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span><span class="mi">2</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">Person</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
living_city <span class="o">=</span> models<span class="o">.</span>ForeignKey<span class="p">(</span>City<span class="p">)</span>
born_city <span class="o">=</span> models<span class="o">.</span>ForeignKey<span class="p">(</span>City<span class="p">,</span> related_name<span class="o">=</span><span class="s1">'born_city_set'</span><span class="p">)</span>
</pre></div></div><p>
When I go to admin to add a new <code>Person</code>, I have the option to add a city at <code>living_city</code> select and <code>born_city</code> select, if I add a city at <code>living_city</code> select, for example, the <code>born_city</code> select does not update automatically, it remains empty or without the new option.
</p>
Resultshttps://code.djangoproject.com/ticket/11803#changeloghttps://code.djangoproject.com/ticket/11929
https://code.djangoproject.com/ticket/11929#11929: manage.py dumpdata outputs YAML in unhelpful orderTue, 22 Sep 2009 16:28:43 GMTsampablokuper<p>
The <a class="ext-link" href="http://docs.djangoproject.com/en/dev/howto/initial-data/"><span class="icon">​</span>docs</a> suggest providing initial YAML data in the following format:
</p>
<pre class="wiki">- model: myapp.person
pk: 1
fields:
first_name: John
last_name: Lennon
</pre><p>
but the manage.py dumpdata outputs YAML in the following form:
</p>
<pre class="wiki">- fields: {first_name: John, last_name: Lennon}
model: myapp.person
pk: 1
</pre><p>
The fact that this is flow rather than block style YAML is the subject of <a class="ext-link" href="http://code.djangoproject.com/ticket/11927"><span class="icon">​</span>#11927</a>, but there's another problem, which is that rather than putting the model and PK first (which is most human-readable), dumpdata outputs the fields first.
</p>
Resultshttps://code.djangoproject.com/ticket/11929#changeloghttps://code.djangoproject.com/ticket/11964
https://code.djangoproject.com/ticket/11964#11964: Add the ability to use database-level CHECK CONSTRAINTSTue, 29 Sep 2009 06:54:51 GMTMatthew Schinckel<p>
I mentioned adding database level CHECK CONSTRAINTS in a post on django-developers.
</p>
<p>
<a class="ext-link" href="http://groups.google.com/group/django-developers/browse_thread/thread/38937992972c7808"><span class="icon">​</span>http://groups.google.com/group/django-developers/browse_thread/thread/38937992972c7808</a>
</p>
<p>
Attached to this ticket is a patch that provides the functionality listed in the first post of this thread. This is not complete: it only allows simple constraints, and is missing a complete test suite.
</p>
Resultshttps://code.djangoproject.com/ticket/11964#changeloghttps://code.djangoproject.com/ticket/12007
https://code.djangoproject.com/ticket/12007#12007: djangoadmin loaddata gives odd error if it runs out of memorySat, 10 Oct 2009 08:55:07 GMTchrisw<p>
Hi All,
</p>
<p>
I tried to import a 3.2GB xml file, partly to see if Django loads the whole file into memory when it's importing and partly to see how large pg client transactions work. Whichever caused the problem, I have a fair idea that even thought the machine has 4GB of memory, the process ran out of memory.
</p>
<p>
I'd expect a MemoryError if that were the case, what I actually got was:
</p>
<pre class="wiki"> File "django/core/management/__init__.py", line 362, in execute_manager
utility.execute()
File "/django/core/management/__init__.py", line 303, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "django/core/management/base.py", line 195, in run_from_argv
self.execute(*args, **options.__dict__)
File "django/core/management/base.py", line 222, in execute
output = self.handle(*args, **options)
File "django/core/management/commands/loaddata.py", line 200, in handle
transaction.leave_transaction_management()
File "django/db/transaction.py", line 74, in leave_transaction_management
raise TransactionManagementError("This code isn't under transaction management")
django.db.transaction.TransactionManagementError: This code isn't under transaction management
</pre><p>
cheers,
</p>
<p>
Chris
</p>
Resultshttps://code.djangoproject.com/ticket/12007#changeloghttps://code.djangoproject.com/ticket/12044
https://code.djangoproject.com/ticket/12044#12044: Add extra_context to admin action delete_selectedFri, 16 Oct 2009 16:06:11 GMTrjc<p>
We need to pass extra context in admin action delete_selected, just like admin view's delete_view.
</p>
Resultshttps://code.djangoproject.com/ticket/12044#changeloghttps://code.djangoproject.com/ticket/12075
https://code.djangoproject.com/ticket/12075#12075: Add wsgiorg.routing args supportThu, 22 Oct 2009 16:06:12 GMTGustavo Narea<p>
The <a class="ext-link" href="http://wsgi.readthedocs.org/en/latest/specifications/routing_args.html"><span class="icon">​</span>wsgiorg.routing_args</a> standard may be really useful if you want to use WSGI middleware or applications inside Django because some of them take advantage of that to do nice/useful things.
</p>
<p>
It's currently not supported in Django - But it will with the attached patch.
</p>
<p>
<em>[edit] fixed broken link.</em>
</p>
Resultshttps://code.djangoproject.com/ticket/12075#changeloghttps://code.djangoproject.com/ticket/12096
https://code.djangoproject.com/ticket/12096#12096: Model fields are not accessible as attributes of the model classTue, 27 Oct 2009 15:45:45 GMTsejo<p>
When using attribute docstrings in my models they will never be picked up by doctools as the attributes disappear top level from the model.
This makes me to keep separate documentation and code for djagios.
</p>
Resultshttps://code.djangoproject.com/ticket/12096#changeloghttps://code.djangoproject.com/ticket/12134
https://code.djangoproject.com/ticket/12134#12134: contrib.admin.RelatedFieldWidgetWrapper.__deepcopy__() should copy() the widget attrsTue, 03 Nov 2009 05:14:21 GMTJames Bennett<p>
Otherwise it ends up with a shallow copy which reuses the same attrs dict across separate widget instances, playing merry hell with form classes which want to change widget attrs on a per-(form)-instance basis.
</p>
Resultshttps://code.djangoproject.com/ticket/12134#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/12227
https://code.djangoproject.com/ticket/12227#12227: PREPEND_WWW breaks the test clientMon, 16 Nov 2009 19:40:40 GMTAndy Baker<p>
With PREPEND_WWW set to true the test client will always give a 301 status_code:
</p>
<pre class="wiki"> &gt;&gt;&gt; from django.test.client import Client
&gt;&gt;&gt; c = Client()
&gt;&gt;&gt; r = c.get('/admin/', follow=True)
&gt;&gt;&gt; r.status_code
301
&gt;&gt;&gt; r.redirect_chain
[('http://www.testserver/admin/', 301), ('http://www.testserver/admin/', 301)]
</pre>Resultshttps://code.djangoproject.com/ticket/12227#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 <code>__init__</code>), ModelAdmin ignores these fields when rendering the form. If one of these fields is added to the ModelForm's <code>Meta</code>, the field shows up just fine.
</p>
<p>
I would expect the field to display without the coaxing in <code>Meta.fields</code>.
</p>
<ol><li>Create a ModelForm
</li><li>Add it to ModelAdmin
</li><li>View Form
</li><li>Update ModelForm's <code>__init__</code> to include <code>self.fields['xyz'] = forms.CharField(max_length=255, initial='keke')</code>
</li><li>View Form (note no change)
</li><li>Update ModelForm's <code>Meta.fields</code> to include "xyz"
</li><li>View Form (note the change)
</li></ol>Resultshttps://code.djangoproject.com/ticket/12238#changeloghttps://code.djangoproject.com/ticket/12246
https://code.djangoproject.com/ticket/12246#12246: contrib.admin's JavaScript functions should be namespacedThu, 19 Nov 2009 16:11:21 GMTitalomaia<p>
Some methods clash with some frameworks. addEvent is used in mootools and django-admin scripts.
</p>
<p>
<strong>Possible solution</strong>
<br />
# from FunFactor, IRC - mootools<br />
var django = {}; django.addEvent = function(...);
</p>
Resultshttps://code.djangoproject.com/ticket/12246#changeloghttps://code.djangoproject.com/ticket/12264
https://code.djangoproject.com/ticket/12264#12264: calendar.js depends on jsi18n but date widgets using it do not specify as required mediaWed, 25 Nov 2009 17:51:43 GMTtblanchard@…<p>
Its nice that we can just use the admin widgets in our own public forms - except trying to include the split date/time widget results in a need for gettext which is in the jsi18n package which requires a separate urlconf entry and view to pull into my app. This is messy. Dependent code should automatically pull in its dependencies.
</p>
Resultshttps://code.djangoproject.com/ticket/12264#changeloghttps://code.djangoproject.com/ticket/12382
https://code.djangoproject.com/ticket/12382#12382: Deleting an inline can delete the whole inlined model instance recursivelyTue, 15 Dec 2009 16:05:57 GMTDirk Eschler<p>
A deleted inline can delete the whole inlined model (and all its related ForeignKeys) if the inlined model has a ForeignKey back to model it inlines. As this is best illustrated by an example, here's some code:
</p>
<p>
models.py:
</p>
<pre class="wiki">class Telephone(models.Model):
TELEPHONE_TYPES = ( ('WORK', 'Work'),
('HOME', 'Home'),
)
telephone_type = models.CharField(max_length=16, choices=TELEPHONE_TYPES)
number = models.CharField(max_length=100)
contact = models.ForeignKey('Contact')
# ...
class Contact(models.Model):
family_name = models.CharField(max_length=255, null=True, blank=True)
given_name = models.CharField(max_length=255, null=True, blank=True)
# ...
preferred_telephone = models.ForeignKey(Telephone, related_name='preferred_telephone', null=True, blank=True)
</pre><p>
admin.py:
</p>
<pre class="wiki">from
class TelephoneInline(admin.TabularInline):
model = Telephone
class TelephoneAdmin(admin.ModelAdmin):
# ...
class ContactAdmin(admin.ModelAdmin):
# ...
inlines = [
TelephoneInline,
]
</pre><p>
Steps:
</p>
<ul><li>Create a contact with a telephone number through the admin and save it
</li><li>Choose the new telephone number as preferred_telephone and save the contact
</li><li>Check the delete checkbox for the telephone number
</li><li>Save
</li></ul><p>
Expected:
</p>
<p>
The telephone number is deleted.
</p>
<p>
Result:
</p>
<p>
The contact is deleted recursively! In addition a 404 is raised that the contact doesn't exist, which is true.
</p>
<p>
If the Contact model had more relations, like a ForeignKey relation to an Address model for instance, all the addresses of the contact would have been deleted, too.
</p>
Resultshttps://code.djangoproject.com/ticket/12382#changeloghttps://code.djangoproject.com/ticket/12416
https://code.djangoproject.com/ticket/12416#12416: Improve KML SerializationMon, 21 Dec 2009 10:37:49 GMTjbronn<p>
Currently, there are several problems with the way KML is generated inside GeoDjango:
</p>
<ol><li>Now that 3D is supported, there is no way to specify the following element tags, which are important to displaying them in Google Earth: <code>&lt;altitudeMode&gt;</code>, <code>&lt;extrude&gt;</code>, and <code>&lt;tessellate&gt;</code>.
</li></ol><ol start="2"><li>A Z value of 0 needs to be omitted for geometries that are purely 2D (this primarily affects the <code>GEOSGeometry.kml</code> property)
</li></ol><ol start="3"><li>Allow specification of an <code>id</code> for geometries, so that styling rules may be easily applied by the user.
</li></ol><ol start="4"><li>For polygons: "the <code>&lt;coordinates&gt;</code> for polygons must be specified in counterclockwise order. Polygons follow the "right-hand rule," which states that if you place the fingers of your right hand in the direction in which the coordinates are specified, your thumb points in the general direction of the geometric normal for the polygon." <a class="ext-link" href="http://code.google.com/apis/kml/documentation/kmlreference.html#polygon"><span class="icon">​</span>KML Reference</a>. I'm not sure about implementing this within the 'dumb' <code>kml</code> properties of <code>GEOSGeometry</code> and <code>OGRGeometry</code>, rather <code>GeoQueryset.kml</code> should wrap <code>ST_AsKml</code> in the necessary routines, e.g., <code>ST_Reverse(ST_ForceRHR(ST_AsKml(the_geom)))</code>.
</li></ol><p>
Attached is an initial idea for a <code>write_kml</code> routine.
</p>
Resultshttps://code.djangoproject.com/ticket/12416#changelog