Django: Ticket Queryhttps://code.djangoproject.com/query?status=!closed&needs_better_patch=0&needs_tests=1&needs_docs=0&has_patch=1&stage=Accepted&order=id
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&needs_tests=1&needs_docs=0&has_patch=1&stage=Accepted&order=id
Trac 1.2https://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/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/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/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/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/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/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/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/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/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/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/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/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/12410
https://code.djangoproject.com/ticket/12410#12410: add support for St_Line_Locate_Point to geodjango postgis backendSun, 20 Dec 2009 17:06:16 GMTIanWard<p>
Here's a patch that adds a line_locate_point method to the GeoQuerySet class, allowing a calculation of the closest point along a LineString to a point field. The value returned is a float between 0 and 1. This is useful for estimating addresses and ordering points given a LineString reference.
</p>
Resultshttps://code.djangoproject.com/ticket/12410#changeloghttps://code.djangoproject.com/ticket/12780
https://code.djangoproject.com/ticket/12780#12780: Provide a hook for compound form/formset validation in ModelAdminThu, 04 Feb 2010 22:46:02 GMTmrts<p>
Sometimes it is necessary to validate inline formset data based on the main form data and vice-versa.
</p>
<p>
See e.g. <a class="ext-link" href="http://groups.google.com/group/django-users/browse_thread/thread/259c1679ddaaceb8/6ad3698e5451d3fe"><span class="icon">​</span>http://groups.google.com/group/django-users/browse_thread/thread/259c1679ddaaceb8/6ad3698e5451d3fe</a> for a use case.
</p>
<p>
My use case is somewhat similar: an object can be published only if its associated items meet certain criteria. Thus, to validate the "is published" flag in the form, access to formsets is required.
</p>
<p>
For advanced users a simple change is sufficient: substitute <code>if all_valid(formsets) and form_validated:</code> with <code>if self.formsets_are_valid(formsets, form, form_validated) and form_validated:</code> in <code>admin/options.py</code>, where <code>def formset_are_valid(self, formsets, ...): return all_valid(formsets)</code>. The latter can then be overriden for arbitrary further manipulations. Will upload a patch eventually.
</p>
<p>
However, this means that people have to mess with either <code>Form</code> or <code>FormSet</code> internals directly (<code>_non_form_errors</code> etc) to expose the errors.
</p>
<p>
This is yet another proof of a conceptual problem, quoting myself from <a class="ext-link" href="http://groups.google.com/group/django-developers/browse_thread/thread/f9aae709a7fda689/fb16a17ab6a31931"><span class="icon">​</span>http://groups.google.com/group/django-developers/browse_thread/thread/f9aae709a7fda689/fb16a17ab6a31931</a> :
</p>
<p>
"<em>Inline formsets usually represent
composition, i.e. the inline objects are inseparable from the
main entity. The relation is stronger than a ForeignKey (from the
main entity to another entity), yet the latter is displayed as a
field of the form and can be easily manipulated -- but not the inlines.</em>"
</p>
<p>
So, this is yet another reason for introducing FormsetFields in the long run -- <code>Form.clean()</code> would have access to formsets both in the admin and ordinary forms.
</p>
Resultshttps://code.djangoproject.com/ticket/12780#changeloghttps://code.djangoproject.com/ticket/15610
https://code.djangoproject.com/ticket/15610#15610: Generic Foreign Keys break when used with multi-db.Tue, 15 Mar 2011 02:56:21 GMTlegutierr<p>
Specifically, retrieving and saving objects that use the GenericForeignKey descriptor fails when the ContentType table is stored in a different database than the table of the instance being retrieved or saved.
</p>
<p>
There can only be one valid and consistent content-type table in a system. In a two-db system, the content type table will be in either db A or db B. Therefore, a portion of the system's tables will be registered in a content-type table that is stored in a different database.
</p>
<p>
This is all OK when retrieving objects based on a GenericForeignKey reference, because a user in such a situation will typically rely on the underlying routers to determine which database to use in retrieving content-type records.
</p>
<p>
However, this method in <a class="ext-link" href="http://code.djangoproject.com/browser/django/trunk/django/contrib/contenttypes/generic.py#L52"><span class="icon">​</span>django/trunk/django/contrib/contenttypes/generic.py</a> does not use routers in determining what database to use to fetch the content-type, but instead uses the source database of the orm object the content-type of which is being queried:
</p>
<pre class="wiki">52 def get_content_type(self, obj=None, id=None, using=None):
53 # Convenience function using get_model avoids a circular import when
54 # using this model
55 ContentType = get_model("contenttypes", "contenttype")
56 if obj:
57 return ContentType.objects.db_manager(obj._state.db).get_for_model(obj)
58 elif id:
59 return ContentType.objects.db_manager(using).get_for_id(id)
60 else:
61 # This should never happen. I love comments like this, don't you?
62 raise Exception("Impossible arguments to GFK.get_content_type!")
</pre><p>
The above method is what is used at object-creation time to transform a generic object in the <code>__init__</code> kwargs of a new orm object into a content-type/object-id pair for purposes of saving. The use of this method results in either: (a) an error being generated when the specified table is not to be found in the designated database; or (b) incorrect information being saved when a parallel--but incorrect (according to the router rules)--content type table from the other database is used (i.e. database corruption).
</p>
<p>
A simple fix would be to not assume that the content-types table is in the same database as the object with the GenericForeignKey field. I don't have a patch right now, but it may be as simple as replacing line 57:
</p>
<pre class="wiki">57 return ContentType.objects.db_manager(obj._state.db).get_for_model(obj)
</pre><p>
with:
</p>
<pre class="wiki">57 return ContentType.objects.db_manager(using).get_for_model(obj)
</pre><p>
A similar error seems to exist in the following block of code as well, however:
</p>
<pre class="wiki">220 manager = RelatedManager(
221 model = rel_model,
222 instance = instance,
223 symmetrical = (self.field.rel.symmetrical and instance.__class__ == rel_model),
224 join_table = qn(self.field.m2m_db_table()),
225 source_col_name = qn(self.field.m2m_column_name()),
226 target_col_name = qn(self.field.m2m_reverse_name()),
227 content_type = ContentType.objects.db_manager(instance._state.db).get_for_model(instance),
228 content_type_field_name = self.field.content_type_field_name,
229 object_id_field_name = self.field.object_id_field_name
230 )
</pre><p>
Requiring that line 227 be replaced, perhaps:
</p>
<pre class="wiki">227 content_type = ContentType.objects.get_for_model(instance),
</pre><p>
The problem here is that no <code>using</code> argument is specified for the <code>__get__</code> method, nor can a <code>using</code> argument be specified there, making the usage in that function inconsistent with the rest of the file, should this fix be put in place.
</p>
Resultshttps://code.djangoproject.com/ticket/15610#changeloghttps://code.djangoproject.com/ticket/15691
https://code.djangoproject.com/ticket/15691#15691: TEST_DEPENDENCIES doesn't use TEST_NAME in circular dependency detection.Fri, 25 Mar 2011 21:17:10 GMTslinkp@…<p>
As far as I can tell, TEST_DEPENDENCIES checks for circular dependencies by looking at the NAME key, ignoring TEST_NAME if it exists.
</p>
<p>
This means that if you have some aliases that use the same NAME but different TEST_NAMEs, it will bail out reporting a circular dependency even though there isn't one. Example:
</p>
<pre class="wiki">DATABASES = {
'default': {
'NAME': 'mydb',
...
'TEST_NAME': 'test_mydb',
'TEST_DEPENDENCIES': ['users'],
},
'users': {
'NAME': 'mydb',
...
'TEST_NAME': 'test_users',
'TEST_DEPENDENCIES': [],
},
</pre><p>
It's reasonable to ask why you'd have multiple database configs with the same NAME. On OpenBlock we've been doing that as our default setup, because most of our dev rigs and deployments use only one physical database, but when running tests we want to be sure that multi-database setups work.
</p>
Resultshttps://code.djangoproject.com/ticket/15691#changeloghttps://code.djangoproject.com/ticket/15982
https://code.djangoproject.com/ticket/15982#15982: Lack DateTime formats in some languagesMon, 09 May 2011 11:22:03 GMTPablo Martín<p>
Lack DateTime formats in some languages.
</p>
<p>
For example in english:
</p>
<pre class="wiki">
DATETIME_INPUT_FORMATS = (
'%Y-%m-%d %H:%M:%S', # '2006-10-25 14:30:59'
'%Y-%m-%d %H:%M', # '2006-10-25 14:30'
'%Y-%m-%d', # '2006-10-25'
'%m/%d/%Y %H:%M:%S', # '10/25/2006 14:30:59'
'%m/%d/%Y %H:%M', # '10/25/2006 14:30'
'%m/%d/%Y', # '10/25/2006'
'%m/%d/%y %H:%M:%S', # '10/25/06 14:30:59'
'%m/%d/%y %H:%M', # '10/25/06 14:30'
'%m/%d/%y', # '10/25/06'
)
</pre><p>
But in spanish, I think that it lacks this format <code> '%d/%m/%y' </code>:
</p>
<pre class="wiki">
DATETIME_INPUT_FORMATS = (
'%d/%m/%Y %H:%M:%S',
'%d/%m/%Y %H:%M',
'%d/%m/%y %H:%M:%S',
'%d/%m/%y %H:%M',
)
</pre>Resultshttps://code.djangoproject.com/ticket/15982#changeloghttps://code.djangoproject.com/ticket/16027
https://code.djangoproject.com/ticket/16027#16027: Include app_label in ContentType.__unicode__Sat, 14 May 2011 22:43:48 GMTJakub Roztočil<p>
When there are multiple models with same name in your project and you use the amazing content types framework, then selects for foreign keys to ContentType contain indistinguishable items. To fix this, the app_label needs to be included in ContentType's <span class="underline">unicode</span>.
</p>
Resultshttps://code.djangoproject.com/ticket/16027#changeloghttps://code.djangoproject.com/ticket/16063
https://code.djangoproject.com/ticket/16063#16063: Problem with searching in m2m fields in inherited modelSat, 21 May 2011 08:25:42 GMTEvgeny Sizikov<p>
Django 1.2.5
</p>
<p>
Models:
</p>
<pre class="wiki">class Client(models.Model):
name = models.CharField(_('name'), max_length=256)
name2 = models.CharField(_('unofficial or obsolete name'), max_length=256, blank=True, null=True)
contact_person = models.CharField(_('contact person'), max_length=256, blank=True, null=True)
...
class ClientOffice(models.Model):
name = models.CharField(_('name'), max_length=256)
name2 = models.CharField(_('unofficial or obsolete name'), max_length=256, blank=True, null=True)
...
client = models.ForeignKey(Client, verbose_name=_('client'))
...
</pre><p>
and admin options like these:
</p>
<pre class="wiki">class ClientAdmin(admin.ModelAdmin):
search_fields = ('name', 'name2', 'contact_person', 'clientoffice__name', 'clientoffice__name2')
...
</pre><p>
Numbers:
</p>
<pre class="wiki">&gt;&gt;&gt; Client.objects.count()
10907
&gt;&gt;&gt; ClientOffice.objects.count()
16952
</pre><p>
Now, if we try searching for clients in admin by a search query containig several words (&gt;3), got django/admin stalled.
</p>
<p>
The problem is going to be that each word in the search query leads to additional JOIN in final SQL query beacause of <code> qs = qs.filter(...) </code> pattern. The attached patch is for Django 1.2.5, but adopting for the current SVN trunk is trivial.
</p>
Resultshttps://code.djangoproject.com/ticket/16063#changeloghttps://code.djangoproject.com/ticket/16281
https://code.djangoproject.com/ticket/16281#16281: ContentType.get_object_for_this_type using wrong database for creating objectThu, 16 Jun 2011 09:29:37 GMTtfrydrychewicz@…<p>
There is a subtle error in <a class="ext-link" href="https://docs.djangoproject.com/en/1.3/ref/contrib/contenttypes/#django.contrib.contenttypes.models.ContentType.get_object_for_this_type"><span class="icon">​</span>ContentType.get_object_for_this_type</a> method.
</p>
<pre class="wiki">def get_object_for_this_type(self, **kwargs):
return self.model_class()._default_manager.using(self._state.db).get(**kwargs)
</pre><p>
Database used to <em>get</em> <em>model_class</em> object is taken from self._state.db, which provides an error when <em>contenttype</em> model is hold in one database and model, of which object we're going to create, in another one.
</p>
<p>
Database should be provided using self.model_class().objects.db not self._state.db.
</p>
Resultshttps://code.djangoproject.com/ticket/16281#changeloghttps://code.djangoproject.com/ticket/17834
https://code.djangoproject.com/ticket/17834#17834: ETag generated from empty content can break http cachingMon, 05 Mar 2012 15:48:27 GMTPaul Egan<p>
The [source:/django/trunk/django/utils/cache.py?rev=17286#L100 patch_response_headers] function will set an ETag header using an md5 hash of the response content. Many responses like redirects can have an empty body and this results in the same ETag for each such response. The response headers may vary but an intermediate cache can serve an incorrect response because the ETag is not unique.
</p>
<p>
A simple solution is to not set ETag if the content is empty - see attached patch.
</p>
<div class="wiki-code"><div class="code"><pre><span class="o">&gt;&gt;&gt;</span> <span class="kn">from</span> <span class="nn">django.http</span> <span class="kn">import</span> HttpResponseRedirect
<span class="o">&gt;&gt;&gt;</span> <span class="kn">from</span> <span class="nn">django.utils.cache</span> <span class="kn">import</span> patch_response_headers
<span class="o">&gt;&gt;&gt;</span> r1 <span class="o">=</span> HttpResponseRedirect<span class="p">(</span><span class="s1">'/u1'</span><span class="p">)</span>
<span class="o">&gt;&gt;&gt;</span> patch_response_headers<span class="p">(</span>r1<span class="p">)</span>
<span class="o">&gt;&gt;&gt;</span> r2 <span class="o">=</span> HttpResponseRedirect<span class="p">(</span><span class="s1">'/u2'</span><span class="p">)</span>
<span class="o">&gt;&gt;&gt;</span> patch_response_headers<span class="p">(</span>r2<span class="p">)</span>
<span class="o">&gt;&gt;&gt;</span> r1<span class="p">[</span><span class="s1">'ETag'</span><span class="p">]</span> <span class="o">==</span> r2<span class="p">[</span><span class="s1">'ETag'</span><span class="p">]</span>
<span class="bp">True</span>
</pre></div></div>Resultshttps://code.djangoproject.com/ticket/17834#changeloghttps://code.djangoproject.com/ticket/17905
https://code.djangoproject.com/ticket/17905#17905: Admin documentation lists all models, even for users without access to certain applicationsThu, 15 Mar 2012 13:20:41 GMTchriscohoat<p>
By default, the admin docs lists documentation for all models. Some users may not have access to models that are still listed in their entirety.
</p>
<p>
The easiest way to fix this was to check each model in the model index, and only add the model to the listing if a user has the correct permissions. I'm not sure if this is the correct way to go about this, but I'm submitting the patch for review.
</p>
Resultshttps://code.djangoproject.com/ticket/17905#changeloghttps://code.djangoproject.com/ticket/18296
https://code.djangoproject.com/ticket/18296#18296: Make creating apps inside project folder more intuitive with manage.py startapp commandThu, 10 May 2012 07:14:49 GMTlgp171188@…<p>
The structure of the project created by 'django-admin.py startproject' has changed from Django 1.4. The 'manage.py' file is at the same level where the project folder containing settings.py, urls.py is present. In order to create an app within the project as was possible with Django &lt; 1.4, the command to be used is 'python manage.py startapp &lt;app name&gt; &lt;destination folder which is optional&gt;. So if I execute the command "python manage.py startapp myapp myproject", there is an error that says "Error: &lt;full path&gt;/&lt;project name&gt;/&lt;project name&gt;/<span class="underline">init</span>.py already exists, overlaying a project or app into an existing directory won't replace conflicting files". The command actually expects an empty directory having the name of the app inside the project directory to work correctly. So the user has to create that directory and then create the app. This isn't very intuitive and django should create the app directory if it doesn't exist and then create the app to show the same behaviour as the previous versions.
</p>
<p>
One other way to work around this behaviour is to change to the project directory and then execute python ../manage.py startapp appname.
</p>
Resultshttps://code.djangoproject.com/ticket/18296#changeloghttps://code.djangoproject.com/ticket/18597
https://code.djangoproject.com/ticket/18597#18597: `BaseInlineFormSet` should attempt to get it's queryset from it's instance related manager before falling back to it's model's default managerMon, 09 Jul 2012 01:19:52 GMTSimon Charette<p>
The newly introduced <code>prefetch_related</code> method can be quite handy to avoid unnecessary queries (thanks Luke :), however it's quite useless when used with <code>BaseInlineFormSet</code> since <a class="ext-link" href="https://github.com/django/django/blob/4a103086d5c67fa4fcc53c106c9fdf644c742dd8/django/forms/models.py#L694"><span class="icon">​</span>it won't even try to get its needed `queryset` from the related manager</a>.
</p>
<p>
i.e.
</p>
<div class="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">Author</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
name <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>max_length<span class="o">=</span><span class="mi">255</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">Book</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
name <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>max_length<span class="o">=</span><span class="mi">255</span><span class="p">)</span>
author <span class="o">=</span> models<span class="o">.</span>ForeignKey<span class="p">(</span>Author<span class="p">,</span> related_name<span class="o">=</span><span class="s1">'books'</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
<span class="c1"># Needed because `BaseModelFormSet.get_query_set` wants an ordered set or issue another query</span>
ordering <span class="o">=</span> <span class="p">(</span><span class="s1">'pk'</span><span class="p">,)</span>
</pre></div></div><pre class="wiki">In [1]: from django.conf import settings
In [2]: from django.db import connection
In [3]: from library.models import *
In [4]: from django.forms.models import inlineformset_factory
In [5]: a = Author.objects.create(name='David Abram')
In [6]: b1 = Book.objects.create(name='Becoming Animal', author=a)
In [7]: b2 = Book.objects.create(name='The Spell of the Sensuous', author=a)
In [8]: BookInlineFormSet = inlineformset_factory(Author, Book)
In [9]: settings.DEBUG = True
In [10]: instance = Author.objects.prefetch_related('books').get()
In [11]: BookInlineFormSet(instance=instance)
Out[11]: &lt;django.forms.formsets.BookFormFormSet at 0x3c68d50&gt;
In [12]: print connection.queries
[{u'time': u'0.000', u'sql': u'SELECT "library_author"."id", "library_author"."name" FROM "library_author"'},
{u'time': u'0.000', u'sql': u'SELECT "library_book"."id", "library_book"."name", "library_book"."author_id" FROM "library_book" WHERE "library_book"."author_id" IN (1) ORDER BY "library_book"."id" ASC'},
{u'time': u'0.000', u'sql': u'SELECT "library_book"."id", "library_book"."name", "library_book"."author_id" FROM "library_book" WHERE "library_book"."author_id" = 1 ORDER BY "library_book"."id" ASC'}]
</pre><p>
I guess it's only a matter of time before people start trying to optimize their formsets (or their <code>ModelAdmin</code> by overriding <code>get_queryset</code>) and stumble on this <em>limitation</em>.
</p>
<p>
I've written a patch (I'll create a pull request) for which I'll write tests if this optimization is <em>Accepted</em>.
</p>
Resultshttps://code.djangoproject.com/ticket/18597#changeloghttps://code.djangoproject.com/ticket/19806
https://code.djangoproject.com/ticket/19806#19806: django_bash_completion clobbers upstream completion of ‘python’Tue, 12 Feb 2013 04:44:17 GMTAnders Kaseorg<p>
<code>extras/django_bash_completion</code> now tries to complete <code>python manage.py</code> in addition to <code>./manage.py</code> (<a class="closed ticket" href="https://code.djangoproject.com/ticket/12174" title="#12174: bash completion for python manage.py (closed: fixed)">#12174</a>), but this results in the upstream completion hook for <code>python</code> being entirely clobbered. For example, the upstream hook completes <code>python -Q</code>, but this is lost when loading <code>django_bash_completion</code>:
</p>
<pre class="wiki">$ python -Q &lt;TAB&gt;
new old warn warnall
$ . extras/django_bash_completion
$ python -Q &lt;TAB&gt;
AUTHORS .git/ LICENSE setup.py
CONTRIBUTING.rst .gitattributes MANIFEST.in tests/
django/ .gitignore README.rst .tx/
docs/ .hgignore scripts/
extras/ INSTALL setup.cfg
</pre><p>
That seems like a really unfriendly thing to do, especially on Linux distros where merely installing the Django package pulls in <code>django_bash_completion</code> automatically.
</p>
<p>
I don’t know of a way to install a completion hook for <code>python manage.py</code> without clobbering all of <code>python</code>, so I would propose that the second half of the script (starting at <code>_python_django_completion</code>) should be deleted entirely. Users who want bash completion can type <code>./manage.py</code> or <code>django-admin</code> instead.
</p>
Resultshttps://code.djangoproject.com/ticket/19806#changeloghttps://code.djangoproject.com/ticket/20098
https://code.djangoproject.com/ticket/20098#20098: Add validation for models with the same db_tableWed, 20 Mar 2013 15:10:48 GMTcarsten.klein@…<p>
When declaring two models using a custom db_table setting in the Meta class, I found out that django failed to detect that the two models declared the same db_table and subsequently it will fail on syncdb when trying to create the same table twice.
</p>
<p>
This, of course, was introduced by copy&amp;paste, but at least django should report this on validate instead of failing when trying to syncdb.
</p>
Resultshttps://code.djangoproject.com/ticket/20098#changeloghttps://code.djangoproject.com/ticket/20287
https://code.djangoproject.com/ticket/20287#20287: BaseContext (and it's subclasses) lack emulation of dictionary items()Thu, 18 Apr 2013 19:52:24 GMTKeryn Knight <django@…><p>
Given the Context usually behaves like a dictionary (though underlying it is obviously also a stack), I was somewhat surprised that it has no <code>items()</code> nor <code>iteritems()</code> methods that would allow it to be iterated as one might expect to, though it does have an <code>__iter__()</code> method, which could probably be used if this has any merit.
</p>
Resultshttps://code.djangoproject.com/ticket/20287#changeloghttps://code.djangoproject.com/ticket/22961
https://code.djangoproject.com/ticket/22961#22961: StaticFilesHandler should not run middleware on 404Sat, 05 Jul 2014 06:06:10 GMTWil Tan<p>
When the staticfiles WSGI handler determines that it should handle a given path, but caught a 404 exception, it should not chain to the parent WSGIHandler, but immediately return a response.
</p>
<p>
Otherwise, we would find that middleware gets run. This may have undesired side effects. In our case, we were running a selenium test (LiveServerTestCase) and got session invalidated due to a concurrent request to login and a static file that does not exist (because this latter one went through the session middleware.)
</p>
<p>
I realise that the LiveServerTestCase code has changed in Django 1.7 (which duplicated some of the code in StaticFilesHandler as django.test.testcases.FSFilesHandler)
</p>
<p>
The proposed patch is only for the StaticFilesHandler. I would like to hear from others what they think of this "fix".
</p>
Resultshttps://code.djangoproject.com/ticket/22961#changeloghttps://code.djangoproject.com/ticket/24472
https://code.djangoproject.com/ticket/24472#24472: Define internal types explicitly for related fieldsWed, 11 Mar 2015 09:44:25 GMTAndriy Sokolovskiy<p>
For related fields internal type is not defined explicitly.
For example, if I want to inherit these fields to add some minor changes, I will need to define internal type manually, because some of backend code is related on internal type of the field.
</p>
<p>
Old pull request - <a class="ext-link" href="https://github.com/django/django/pull/4002"><span class="icon">​</span>https://github.com/django/django/pull/4002</a>
</p>
<p>
We discussed here that is a good idea to have this feature in 1.9
</p>
Resultshttps://code.djangoproject.com/ticket/24472#changeloghttps://code.djangoproject.com/ticket/24581
https://code.djangoproject.com/ticket/24581#24581: Explicitly raise an exception if ManyToManyField._get_m2m_attr fails to matchSat, 04 Apr 2015 09:54:10 GMTPatryk Zawadzki<p>
In cases like <a class="closed ticket" href="https://code.djangoproject.com/ticket/24513" title="#24513: Bug: &#34;... has no field named None&#34; with M2MField when migrating (closed: fixed)">#24513</a> it results in surprising error messages and useless tracebacks.
</p>
Resultshttps://code.djangoproject.com/ticket/24581#changeloghttps://code.djangoproject.com/ticket/24810
https://code.djangoproject.com/ticket/24810#24810: Reopen database connection automatically when no transaction is activeSun, 17 May 2015 12:31:37 GMTAymeric Augustin<p>
This is a follow-up of <a class="closed ticket" href="https://code.djangoproject.com/ticket/15802" title="#15802: Cleanup/optimization: Django stops functioning when the database (PostgreSQL) closes the ... (closed: fixed)">#15802</a>.
</p>
<p>
When the database closes the connection, for instance because the database server was restarted, an exception will be raised the next time user code attempts to use the database. Django doesn't attempt to do anything about it.
</p>
<p>
This is expected to result in at most one 500 error for each thread that serves requests, since database connections are thread-local. This doesn't sound horrific. After all the database was restarted while the website was serving requests.
</p>
<p>
It can also cause management commands to crash, which isn't the end of the world either since management commands should fall into one of the following categories:
</p>
<ul><li>short-lived, idempotent and scheduled to run regularly
</li><li>long-lived and supervised to run constantly
</li><li>run manually
</li></ul><p>
If the connection was in autocommit mode and an operation fails because the database has closed the connection, theoretically, it's safe the reopen the connection and retry the operation.
</p>
<p>
In that case, Django could continue to operate transparently instead of raising an exception.
</p>
<p>
This may not be easy to implement.
</p>
Resultshttps://code.djangoproject.com/ticket/24810#changeloghttps://code.djangoproject.com/ticket/26487
https://code.djangoproject.com/ticket/26487#26487: Use EHLO after smtplib.SMTP_SSL too.Sun, 10 Apr 2016 23:37:53 GMTkchmiela<p>
In file django/core/mail/backends/smtp.py after smtplib.SMTP_SSL EHLO should be used.
</p>
Resultshttps://code.djangoproject.com/ticket/26487#changeloghttps://code.djangoproject.com/ticket/26552
https://code.djangoproject.com/ticket/26552#26552: `TransactionTestCase.serialized_rollback` fails to restore objects due to ordering constraintsThu, 28 Apr 2016 07:25:09 GMTAymeric Augustin<p>
I hit this problem in a fairly complex projet and haven't had the time to write a minimal reproduction case. I think it can be understood just by inspecting the code so I'm going to describe it while I have it in mind.
</p>
<hr />
<p>
Setting <code>serialized_rollback = True</code> on a <code>TransactionTestCase</code> triggers <a class="ext-link" href="https://docs.djangoproject.com/en/1.9/topics/testing/overview/#rollback-emulation"><span class="icon">​</span>rollback emulation</a>. In practice, for each database:
</p>
<ul><li><code>BaseDatabaseCreation.create_test_db</code> calls <code>connection._test_serialized_contents = connection.creation.serialize_db_to_string()</code>
</li><li><code>TransactionTestCase._fixture_setup</code> calls <code>connection.creation.deserialize_db_from_string(connection._test_serialized_contents)</code>
</li></ul><p>
(The actual code isn't written that way; it's equivalent but the symmetry is less visible.)
</p>
<hr />
<p>
<code>serialize_db_to_string</code> orders models with <code>serializers.sort_dependencies</code> and serializes them. The sorting algorithm only deals with natural keys. It doesn't do anything to order models referenced by foreign keys before models containing said foreign keys. That wouldn't be possible in general because circular foreign keys are allowed.
</p>
<p>
<code>deserialize_db_from_string</code> deserializes and saves models without wrapping in a transaction. This can result in integrity errors if an instance containing a foreign key is saved before the instance it references. I'm suggesting to fix it as follows:
</p>
<pre class="wiki">diff --git a/django/db/backends/base/creation.py b/django/db/backends/base/creation.py
index bca8376..7bed2be 100644
--- a/django/db/backends/base/creation.py
+++ b/django/db/backends/base/creation.py
@@ -4,7 +4,7 @@ import time
from django.apps import apps
from django.conf import settings
from django.core import serializers
-from django.db import router
+from django.db import router, transaction
from django.utils.six import StringIO
from django.utils.six.moves import input
@@ -128,8 +128,9 @@ class BaseDatabaseCreation(object):
the serialize_db_to_string method.
"""
data = StringIO(data)
- for obj in serializers.deserialize("json", data, using=self.connection.alias):
- obj.save()
+ with transaction.atomic(using=self.connection.alias):
+ for obj in serializers.deserialize("json", data, using=self.connection.alias):
+ obj.save()
def _get_database_display_str(self, verbosity, database_name):
"""
</pre><hr />
<p>
Note that <code>loaddata</code> doesn't have this problem because it wraps everything in a transaction:
</p>
<pre class="wiki"> def handle(self, *fixture_labels, **options):
# ...
with transaction.atomic(using=self.using):
self.loaddata(fixture_labels)
# ...
</pre><p>
This suggest that the transaction was just forgotten in the implementation of <code>deserialize_db_from_string</code>.
</p>
<hr />
<p>
It should be possible to write a deterministic test for this bug because the order in which <code>serialize_db_to_string</code> serializes models depends on the app registry, and the app registry uses <code>OrderedDict</code> to store apps and models in a deterministic order.
</p>
Resultshttps://code.djangoproject.com/ticket/26552#changeloghttps://code.djangoproject.com/ticket/26605
https://code.djangoproject.com/ticket/26605#26605: Abstract model inheriting concrete model crashes migrationsWed, 11 May 2016 22:12:44 GMTSébastien Diemer<p>
When using Model inheritance with an abstract model in between, it can happen that the _default_manager of the actual child class is None. In this case the <em>ModelState.from_model</em> function fails with the following error:
</p>
<pre class="wiki">django/django/db/migrations/state.py", line 439, in from_model
default_manager_name = force_text(model._default_manager.name)
AttributeError: 'NoneType' object has no attribute 'name'
</pre><p>
The following modified test reproduces the error:
</p>
<pre class="wiki"> @override_settings(TEST_SWAPPABLE_MODEL='migrations.SomeFakeModel')
def test_create_swappable(self):
"""
Tests making a ProjectState from an Apps with a swappable model
"""
new_apps = Apps(['migrations'])
class Base(models.Model):
pass
class AbstractAuthor(Base):
class Meta:
abstract = True
class Author(AbstractAuthor):
name = models.CharField(max_length=255)
bio = models.TextField()
age = models.IntegerField(blank=True, null=True)
class Meta(AbstractAuthor.Meta):
app_label = 'migrations'
apps = new_apps
swappable = 'TEST_SWAPPABLE_MODEL'
author_state = ModelState.from_model(Author)
self.assertEqual(author_state.app_label, 'migrations')
self.assertEqual(author_state.name, 'Author')
self.assertEqual([x for x, y in author_state.fields], ['id', 'name', 'bio', 'age'])
self.assertEqual(author_state.fields[1][1].max_length, 255)
self.assertEqual(author_state.fields[2][1].null, False)
self.assertEqual(author_state.fields[3][1].null, True)
self.assertEqual(author_state.options, {'abstract': False, 'swappable': 'TEST_SWAPPABLE_MODEL'})
self.assertEqual(author_state.bases, (models.Model, ))
self.assertEqual(author_state.managers, [])
</pre><p>
Changing the following line in <em>ModelState.from_model</em>
</p>
<pre class="wiki"> if hasattr(model, "_default_manager"):
</pre><p>
to
</p>
<pre class="wiki"> if getattr(model, "_default_manager", None):
</pre><p>
is probably sufficient to fix the bug.
</p>
<p>
See also PR <a class="ext-link" href="https://github.com/django/django/pull/6847"><span class="icon">​</span>https://github.com/django/django/pull/6847</a>
</p>
Resultshttps://code.djangoproject.com/ticket/26605#changeloghttps://code.djangoproject.com/ticket/27080
https://code.djangoproject.com/ticket/27080#27080: `as_manager` on QuerySet should pass down `use_in_migrations` to new Manager instanceThu, 18 Aug 2016 00:19:12 GMTLeif Denby<p>
When using the convenience method <code>as_manager</code> on a QuerySet the attribute <code>is_in_migrations</code> (<a class="ext-link" href="https://docs.djangoproject.com/en/1.9/topics/migrations/#model-managers"><span class="icon">​</span>https://docs.djangoproject.com/en/1.9/topics/migrations/#model-managers</a>) is currently not passed down. This means that when creating a migration the <code>Manager</code>s which a created from <code>QuerySet</code>s won't be serialised into the migration. The current workaround would be to create Manager class from the QuerySet, thereby using the old approach where <code>QuerySet.as_manager</code> isn't used.
</p>
Resultshttps://code.djangoproject.com/ticket/27080#changeloghttps://code.djangoproject.com/ticket/27522
https://code.djangoproject.com/ticket/27522#27522: ./manage runserver --nostatic doesn't return a tracebackTue, 22 Nov 2016 08:48:43 GMTJeroen van Veen<p>
When running ./manage runserver --nostatic, I expect a traceback to be returned when
a syntax error occurs, and I expect the autoreloader still to be available. Instead, the
runserver command exits like:
</p>
<pre class="wiki">usage: manage.py runserver [-h] [--version] [-v {0,1,2,3}]
[--settings SETTINGS] [--pythonpath PYTHONPATH]
[--traceback] [--no-color] [--ipv6] [--nothreading]
[--noreload]
[addrport]
manage.py runserver: error: unrecognized arguments: --nostatic
</pre><p>
Ticket: <a class="ext-link" href="https://github.com/wearespindle/django/tree/ticket_27522"><span class="icon">​</span>https://github.com/wearespindle/django/tree/ticket_27522</a>
</p>
Resultshttps://code.djangoproject.com/ticket/27522#changeloghttps://code.djangoproject.com/ticket/27533
https://code.djangoproject.com/ticket/27533#27533: inspectdb crashes on unsupported unique_together constraints in PostgreSQLFri, 25 Nov 2016 00:15:41 GMTWei Ma<p>
inspectdb command crashes when I try to generate model classes from postgres db.
</p>
<p>
the command I used was
python manage.py inspectdb &gt; all_models.py
</p>
<p>
the error I got was:
</p>
<p>
File "/xxx/env/lib/python3.5/site-packages/django/core/management/commands/inspectdb.py", line 278, in &lt;genexpr&gt;
</p>
<blockquote>
<p>
tup = '(' + ', '.join("'%s'" % column_to_field_name[c] for c in columns) + ')'
</p>
</blockquote>
<p>
KeyError: None
</p>
Resultshttps://code.djangoproject.com/ticket/27533#changelog