Re: [Django] #17760: connection.features.supports_transactions is None

[Django]

#17760: connection.features.supports_transactions is None
-+-
 Reporter:  cdestigter   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by charettes):

 FWIW I recently committed a patch to south to use the same approach for
 [https://bitbucket.org/andrewgodwin/south/changeset/00074f0d28e7 DDL
 transaction support detection] and it works quite well.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17759: FormMixin instantiates form with dict stored on the class

[Django]

#17759: FormMixin instantiates form with dict stored on the class
---+--
 Reporter:  agriffis   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Generic views  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by charettes):

 * cc: charette.s@… (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17767: add signed cookie session backed to session engine settings docs

[Django]

#17767: add signed cookie session backed to session engine settings docs
---+
 Reporter:  ptone  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  SVN
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 https://github.com/django/django/pull/116

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17766: Clarify impact of HttpOnly flag for JS access to session cookie

[Django]

#17766: Clarify impact of HttpOnly flag for JS access to session cookie
--+
 Reporter:  ptone |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 https://github.com/django/django/pull/115

 This change impacts anyone accessing the session data from Javascript, for
 example, when relaying the session ID into a querystring in the case of
 flash uploading tools. I'm not opening a debate on whether this is proper
 to do or not, just that it will help people understand possible impacts of
 this change when using other people's code that may do this (as happened
 to me).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r17586 - django/trunk/docs/howto/deployment/wsgi

[noreply]

Author: timo
Date: 2012-02-24 15:24:30 -0800 (Fri, 24 Feb 2012)
New Revision: 17586

Modified:
   django/trunk/docs/howto/deployment/wsgi/uwsgi.txt
Log:
Fixed #17073 - focused uwsgi docs to Django integration; thanks Preston Holmes.

Modified: django/trunk/docs/howto/deployment/wsgi/uwsgi.txt
===
--- django/trunk/docs/howto/deployment/wsgi/uwsgi.txt   2012-02-24 22:54:00 UTC 
(rev 17585)
+++ django/trunk/docs/howto/deployment/wsgi/uwsgi.txt   2012-02-24 23:24:30 UTC 
(rev 17586)
@@ -7,13 +7,8 @@
 uWSGI_ is a fast, self-healing and developer/sysadmin-friendly application
 container server coded in pure C.
 
-It also provides a fast `caching framework`_ but its documentation is not the
-purpose of this document.
-
 .. _uWSGI: http://projects.unbit.it/uwsgi/
-.. _caching framework: http://projects.unbit.it/uwsgi/wiki/CachingFramework
 
-
 Prerequisite: uWSGI
 ===
 
@@ -27,90 +22,28 @@
 # or install LTS (long term support)
 pip install http://projects.unbit.it/downloads/uwsgi-lts.tar.gz
 
-.. _installation procedures: http://projects0.unbit.it/uwsgi/wiki/Install
+.. _installation procedures: http://projects.unbit.it/uwsgi/wiki/Install
 
-Prerequisite: general concept
-=
-
 uWSGI model
 ---
 
 uWSGI operates on a client-server model. Your Web server (ie. nginx, Apache)
 communicates with a django-uwsgi "worker" process to serve dynamic content.
-The Web server can communicate with the uWSGI process either:
+See uWSGI's `background documentation`_ for more detail.
 
-* directly by the uWSGI protocol through a socket created by uWSGI,
-* or by proxying HTTP requests to the minimalist HTTP server built in uWSGI.
+.. _background documentation: http://projects.unbit.it/uwsgi/wiki/Background
 
-In the first case: the Web server can do uWSGI protocol (often with a
-module). It can then use either a Unix domain socket (a "named pipe" on Win32
-systems), or it can use a TCP socket. What you choose is a matterr of
-preference. Usually, a TCP socket is easier because connecting to a port
-doesn't require special permissions.
+Configuring and starting the uWSGI server for Django
+
 
-In the second case, the Web server doesn't need to speak the uWSGI protocol. It
-just needs to be able to proxy HTTP requests to the HTTP server built-in uWSGI.
-The procedure is the same as proxying to any HTTP server. Note that the Web
-server is a "reverse proxy" in this case.
+uWSGI supports multiple ways to configure the process, see uWSGI's
+`configuration documentation`_ and `examples`_
 
-Configuring the uWSGI server
-
+.. _configuration documentation: http://projects.unbit.it/uwsgi/wiki/Doc
+.. _examples: http://projects.unbit.it/uwsgi/wiki/Example
 
-In any case, when you set up your Web server, you'll just need to point its
-uwsgi or proxy module to the host/port or socket you specified when starting
-the uWSGI server.
+An example command to start a uWSGI server::
 
-.. admonition:: Choosing the socket
-
-The easiest is to set the socket to a high level (>49152) local port like
-127.0.0.1:49152. If the socket is a file, the system administrator must
-ensure that the Web server process has read, write and execute privileges
-on that file.
-
-uWSGI is highly configurable and thus there are many ways to start the
-process. For example, uwsgi version 0.9.6.8 provides a hundred switches.  This
-guide demonstrates the most important of them, but is not a substitute the
-official manual and online documentation.
-
-uWSGI supports configuration through:
-
-* environment variables
-* command line switches
-* ldap
-* ini files
-* xml files
-* yaml files
-
-Managing the uWSGI server
--
-
-The system administrator controls the worker process pool by sending signals
-to the master process. For example, the unix kill command sends such signals.
-uWSGI can write the master process id to a "pidfile". A "pidfile" is a plain
-text file containing just a process id.
-
-Starting the server

-
-Starting an uWSGI server is the role of the system administrator, like
-starting the Web server. It is *not* the role of the Web server to start the
-uWSGI server. This means:
-
-* the uWSGI server can be restarted or reloaded independently from the Web
-  server,
-* (except with Cherokee), it is the role of the system administrator to make
-  uWSGI start on boot or reboot: either through tools like supervisor or
-  daemontools, either directly at init level in a file like /etc/rc.local or
-  /etc/conf.d/local
-
-Managing uWSGI
-==
-
-Starting the server

-
-Example command line for a Web server that understands the uWSGI protocol::
-
 uwsgi --chdir=/path/to/your/project
 --module='mysite.wsgi:application' \
 --env DJANGO_SETTINGS_MODULE=mysite.settings

Re: [Django] #17073: focus uwsgi docs to only Django integration

[Django]

#17073: focus uwsgi docs to only Django integration
--+
 Reporter:  ptone |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  SVN
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timo):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [17586]:
 {{{
 #!CommitTicketReference repository="" revision="17586"
 Fixed #17073 - focused uwsgi docs to Django integration; thanks Preston
 Holmes.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r17585 - django/branches/releases/1.3.X/docs/intro

[noreply]

Author: timo
Date: 2012-02-24 14:54:00 -0800 (Fri, 24 Feb 2012)
New Revision: 17585

Modified:
   django/branches/releases/1.3.X/docs/intro/overview.txt
Log:
[1.3.X] Fixed #17757 - Typo in docs/intro/overview.txt; thanks kaushik1618.

Backport of r17584 from trunk.

Modified: django/branches/releases/1.3.X/docs/intro/overview.txt
===
--- django/branches/releases/1.3.X/docs/intro/overview.txt  2012-02-24 
22:53:48 UTC (rev 17584)
+++ django/branches/releases/1.3.X/docs/intro/overview.txt  2012-02-24 
22:54:00 UTC (rev 17585)
@@ -230,7 +230,7 @@
 for templates. If a template doesn't exist in the first directory, it checks 
the
 second, and so on.
 
-Let's say the ``news/article_detail.html`` template was found. Here's what that
+Let's say the ``news/year_archive.html`` template was found. Here's what that
 might look like:
 
 .. code-block:: html+django

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17757: Typo in documentation - "Django at a glance"

[Django]

#17757: Typo in documentation - "Django at a glance"
---+--
 Reporter:  kaushik1618@…  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by timo):

 In [17585]:
 {{{
 #!CommitTicketReference repository="" revision="17585"
 [1.3.X] Fixed #17757 - Typo in docs/intro/overview.txt; thanks
 kaushik1618.

 Backport of r17584 from trunk.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r17584 - django/trunk/docs/intro

[noreply]

Author: timo
Date: 2012-02-24 14:53:48 -0800 (Fri, 24 Feb 2012)
New Revision: 17584

Modified:
   django/trunk/docs/intro/overview.txt
Log:
Fixed #17757 - Typo in docs/intro/overview.txt; thanks kaushik1618.

Modified: django/trunk/docs/intro/overview.txt
===
--- django/trunk/docs/intro/overview.txt2012-02-24 22:50:58 UTC (rev 
17583)
+++ django/trunk/docs/intro/overview.txt2012-02-24 22:53:48 UTC (rev 
17584)
@@ -230,7 +230,7 @@
 for templates. If a template doesn't exist in the first directory, it checks 
the
 second, and so on.
 
-Let's say the ``news/article_detail.html`` template was found. Here's what that
+Let's say the ``news/year_archive.html`` template was found. Here's what that
 might look like:
 
 .. code-block:: html+django

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17757: Typo in documentation - "Django at a glance"

[Django]

#17757: Typo in documentation - "Django at a glance"
---+--
 Reporter:  kaushik1618@…  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by timo):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [17584]:
 {{{
 #!CommitTicketReference repository="" revision="17584"
 Fixed #17757 - Typo in docs/intro/overview.txt; thanks kaushik1618.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17749: Admin documentation on views suggests poor way of adding extra_context

[Django]

#17749: Admin documentation on views suggests poor way of adding extra_context
-+-
 Reporter:  chrisdpratt  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  admin,   |  Needs documentation:  0
  documentation, docs|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by timo):

 In [17583]:
 {{{
 #!CommitTicketReference repository="" revision="17583"
 [1.3.X] Fixed #17749 - Documented better way of overriding ModelAdmin;
 thanks chrisdpratt and claudep.

 Backport of r17582 from trunk.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r17583 - django/branches/releases/1.3.X/docs/ref/contrib/admin

[noreply]

Author: timo
Date: 2012-02-24 14:50:58 -0800 (Fri, 24 Feb 2012)
New Revision: 17583

Modified:
   django/branches/releases/1.3.X/docs/ref/contrib/admin/index.txt
Log:
[1.3.X] Fixed #17749 - Documented better way of overriding ModelAdmin; thanks 
chrisdpratt and claudep.

Backport of r17582 from trunk.

Modified: django/branches/releases/1.3.X/docs/ref/contrib/admin/index.txt
===
--- django/branches/releases/1.3.X/docs/ref/contrib/admin/index.txt 
2012-02-24 22:50:36 UTC (rev 17582)
+++ django/branches/releases/1.3.X/docs/ref/contrib/admin/index.txt 
2012-02-24 22:50:58 UTC (rev 17583)
@@ -1045,11 +1045,10 @@
 pass
 
 def change_view(self, request, object_id, extra_context=None):
-my_context = {
-'osm_data': self.get_osm_info(),
-}
+extra_context = extra_context or {}
+extra_context['osm_data'] = self.get_osm_info()
 return super(MyModelAdmin, self).change_view(request, object_id,
-extra_context=my_context)
+extra_context=extra_context)
 
 ``ModelAdmin`` media definitions
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r17582 - django/trunk/docs/ref/contrib/admin

[noreply]

Author: timo
Date: 2012-02-24 14:50:36 -0800 (Fri, 24 Feb 2012)
New Revision: 17582

Modified:
   django/trunk/docs/ref/contrib/admin/index.txt
Log:
Fixed #17749 - Documented better way of overriding ModelAdmin; thanks 
chrisdpratt and claudep.

Modified: django/trunk/docs/ref/contrib/admin/index.txt
===
--- django/trunk/docs/ref/contrib/admin/index.txt   2012-02-23 22:51:14 UTC 
(rev 17581)
+++ django/trunk/docs/ref/contrib/admin/index.txt   2012-02-24 22:50:36 UTC 
(rev 17582)
@@ -1278,11 +1278,10 @@
 pass
 
 def change_view(self, request, object_id, extra_context=None):
-my_context = {
-'osm_data': self.get_osm_info(),
-}
+extra_context = extra_context or {}
+extra_context['osm_data'] = self.get_osm_info()
 return super(MyModelAdmin, self).change_view(request, object_id,
-extra_context=my_context)
+extra_context=extra_context)
 
 .. versionadded:: 1.4
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17749: Admin documentation on views suggests poor way of adding extra_context

[Django]

#17749: Admin documentation on views suggests poor way of adding extra_context
-+-
 Reporter:  chrisdpratt  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  admin,   |  Needs documentation:  0
  documentation, docs|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by timo):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [17582]:
 {{{
 #!CommitTicketReference repository="" revision="17582"
 Fixed #17749 - Documented better way of overriding ModelAdmin; thanks
 chrisdpratt and claudep.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17424: Using exclude on a queryset with an annotate field gives attribute error.

[Django]

#17424: Using exclude on a queryset with an annotate field gives attribute 
error.
-+-
 Reporter:  joseph.helfer@…  |Owner:  lrekucki
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by glen.nelson.1@…):

 Tested this patch on my django project - it seems to have worked.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16406: Allow separate access to matches from urlpatterns and extra_context args

[Django]

#16406: Allow separate access to matches from urlpatterns and extra_context args
--+
 Reporter:  apollo13  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:  resolvers, reverse| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by anonymous):

 If your patch includes my changes that should be fine…

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16549: In Django models, save/delete preconditions would help in handling optimistic concurrency control problems

[Django]

#16549: In Django models, save/delete preconditions would help in handling
optimistic concurrency control problems
-+-
 Reporter:  estebistec   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by carljm:

Old description:

> Most agree that in webapps one cannot lock rows to be edited ahead of
> time. Optimistic concurrency is the typical choice here. So, it is then
> the job of the appdev to think about how to handle contention when it
> does occur. I've found scenarios when it would have been useful to know
> the rows-modified count for an update or delete:
>
> 1. Models have a "version" field, and we'd like to prevent two requests
> from clobbering each other with updates from the same version. These race
> conditions are generally the way of the web when two people are allowed
> to edit data simultaneously, but there are times when the data is a
> little more critical and we'd like to be able to present the conflict to
> the 2nd user trying to update (e.g., bugzilla mid-air collisions). In
> this case, it would be nice to be able to save() only on the precondition
> that the version in the DB hasn't been updated. At a low level, this
> means something like UPDATE ... WHERE ID = xxx AND VERSION = xxx, and
> then the rows-modified count would indicate whether it worked or not.
> 2. When we really want to know that a delete() call deleted data. Django
> ORM delete() passes silently if the object is already gone. However,
> there are cases when we want to know that the current request actually
> did the delete. One example is deleting OAuth auth codes: they should be
> used once and only once. (Yes, we could just mark it as used, but that
> still leaves us with the update/versioning problem above... and this is
> just an example). If two requests retrieve the auth code and otherwise
> believe they deleted (used) it, this would be considered a potential
> security problem in OAuth.
>
> In both cases, having access to rows modified before commit would help
> greatly towards application-specific optimistic concurrency control
> handling. IFAICT, only that answer from the DB driver can tell us if the
> current request actually got to do a given data update. In looking at the
> django.db.models code it looks like rows-modified is available deep in
> the code, where DB specific connections and cursors are used, but is
> otherwise ignored there.
>
> So, the actual proposal:
> * Model.delete(), QuerySet.update(), and QuerySet.delete() return rows-
> modified counts
> * New Model method save_if() that accepts a precondition, such as
> version=5 (which would be more like F('version')==5 under the covers,
> obviously we want to compare the actual value in storage). If the
> precondition fails, return MyModel.PreconditionFailed, which extends
> ObjectPreconditionFailed. In my example above I would probably translate
> that to a model-specific VersionObsolete exception, or similar.
>
> Thoughts?
>
> I can work on patches, but I wanted to log this first and see what kind
> of reaction it got before spending the time on that.

New description:

 Most agree that in webapps one cannot lock rows to be edited ahead of
 time. Optimistic concurrency is the typical choice here. So, it is then
 the job of the appdev to think about how to handle contention when it does
 occur. I've found scenarios when it would have been useful to know the
 rows-modified count for an update or delete:

 1. Models have a "version" field, and we'd like to prevent two requests
 from clobbering each other with updates from the same version. These race
 conditions are generally the way of the web when two people are allowed to
 edit data simultaneously, but there are times when the data is a little
 more critical and we'd like to be able to present the conflict to the 2nd
 user trying to update (e.g., bugzilla mid-air collisions). In this case,
 it would be nice to be able to save() only on the precondition that the
 version in the DB hasn't been updated. At a low level, this means
 something like UPDATE ... WHERE ID = xxx AND VERSION = xxx, and then the
 rows-modified count would indicate whether it worked or not.
 2. When we really want to know that a delete() call deleted data. Django
 ORM delete() passes silently if the object is already gone. However, there
 are ca

Re: [Django] #16891: [patch] queryset delete should return number of rows matched (was: [patch] Delete/update should return number of rows modified)

[Django]

#16891: [patch] queryset delete should return number of rows matched
-+-
 Reporter:  estebistec   |Owner:
 Type:  New feature  |  estebistec
Component:  Database layer   |   Status:  new
  (models, ORM)  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Description changed by carljm:

Old description:

> Splitting this off from ticket 16549...
>
> Deep in the bowels of django.db the rows modified value from update and
> delete queries is ignored and discarded. For reasons discussed on ticket
> 16549, it would sometimes be useful to have access to that value.
>
> Objective of this bug is to passively return rows-modified up through the
> call-stack and, ultimately, hopefully from each of:
>
> * Model.save()
> * Model.delete()
> * QuerySet.update()
> * QuerySet.delete()
>
> with consideration for transaction control/mgmt.
>
> * https://code.djangoproject.com/ticket/16549

New description:

 Splitting this off from ticket #16549...

 Deep in the bowels of django.db the rows modified value from update and
 delete queries is ignored and discarded. For reasons discussed on ticket
 16549, it would sometimes be useful to have access to that value.

 Objective of this bug is to passively return rows-modified up through the
 call-stack and, ultimately, hopefully from each of:

 * Model.save()
 * Model.delete()
 * QuerySet.update()
 * QuerySet.delete()

 with consideration for transaction control/mgmt.

 **Update from comment thread**: queryset update already returns rows-
 matched (and this can't be changed to rows-changed without breaking other
 things). So it is only deletes that need this change.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17760: connection.features.supports_transactions is None

[Django]

#17760: connection.features.supports_transactions is None
-+-
 Reporter:  cdestigter   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by claudep):

 Thanks for the hint Anssi, it's indeed nicer with the cached_property
 decorator.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17435: document that QuerySet.update returns not the number of rows changed, but the number of rows matched (was: QuerySet.update returns not the number of rows affected, but the number

[Django]

#17435: document that QuerySet.update returns not the number of rows changed, 
but
the number of rows matched
---+
 Reporter:  m17.admin@…|Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17765: Better model 'app_label' introspection using 'INSTALLED_APPS'

[Django]

#17765: Better model 'app_label' introspection using 'INSTALLED_APPS'
-+-
 Reporter:  fengb|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  app_label|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by fengb):

 Crap, I didn't notice that my description formatting gotten eaten...

 Middle "paragraph" should be:

 * django.contrib.auth.models.User -> auth
 * newproj.newapp.models.Newmodel -> newapp
 * newproj.newapp.models.db.Newmodel -> models

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17700: Django formset documentation missing Class Based View Docs

[Django]

#17700: Django formset documentation missing Class Based View Docs
---+--
 Reporter:  rh0dium|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by anonymous):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17765: Better model 'app_label' introspection using 'INSTALLED_APPS'

[Django]

#17765: Better model 'app_label' introspection using 'INSTALLED_APPS'
-+-
 Reporter:  fengb|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  app_label|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

 * needs_better_patch:   => 0
 * needs_tests:   => 1
 * needs_docs:   => 0


Comment:

 I have an implementation available on Github:

 https://github.com/fengb/django/tree/app-label-introspect

 Tests are failing but they look somewhat unrelated.  I do not have enough
 context to fix them.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17765: Better model 'app_label' introspection using 'INSTALLED_APPS'

[Django]

#17765: Better model 'app_label' introspection using 'INSTALLED_APPS'
--+---
 Reporter:  fengb |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:  app_label
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 Currently, the model generates "app_label" by taking the second to last
 module:

 django.contrib.auth.models.User  ->  auth
 newproj.newapp.models.Newmodel  ->  newapp
 newproj.newapp.models.db.Newmodel  ->  models

 The last example doesn't make any sense.  I propose that we match the
 module chain against 'INSTALLED_APPS' to find the correct app.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17764: Documentation out-of-date: django.contrib.auth.utils no longer exists.

[Django]

#17764: Documentation out-of-date: django.contrib.auth.utils no longer exists.
-+-
 Reporter:  mbt  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:
 Severity:  Release blocker  |  1.4-beta-1
 Keywords:  authentication   |   Resolution:
  documentation  easy-pickings   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by claudep):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Thanks for the precise description of the problem. Patch welcome!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16406: Allow separate access to matches from urlpatterns and extra_context args

[Django]

#16406: Allow separate access to matches from urlpatterns and extra_context args
--+
 Reporter:  apollo13  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:  resolvers, reverse| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by antoviaque):

 * owner:  antoviaque => nobody


Comment:

 Looks like you beat me to the update apollo : )

 I've added a test specific to the behavior change though, you may want to
 integrate it in your patch.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17760: connection.features.supports_transactions is None

[Django]

#17760: connection.features.supports_transactions is None
-+-
 Reporter:  cdestigter   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 There is a @cached_property decorator at django/utils/functional.py, it is
 meant for situations like this. Maybe it would make the implementation a
 bit cleaner.

 You could perhaps test that no queries are made after first use of the
 property, but if you use the @cached_property decorator, I don't know how
 necessary that is. It might be better to write a test for the
 @cached_property decorator, and then trust that it does the right thing.
 In short, I don't know if there is any need for additional tests.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #2443: Add IntervalField to database models

[Django]

#2443: Add IntervalField to database models
-+-
 Reporter:  ben.tucker@… |Owner:  Adys
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  IntervalField|  Needs documentation:  0
  interval duration DurationField|  Patch needs improvement:  1
  feature|UI/UX:  1
Has patch:  1|
  Needs tests:  1|
Easy pickings:  0|
-+-

Comment (by smcoll):

 Replying to [comment:50 jpaulett]:
 > While Python does provide the timedelta class, there is no common SQL
 implementation for storing that object in the database.  PostgreSQL does
 provide the INTERVAL data type, MySQL and SQLite do not have any interval
 data type (I am not sure about Oracle, MSSQL, etc.).

 What about MySQL's TIME type?

 "MySQL retrieves and displays TIME values in 'HH:MM:SS' format (or
 'HHH:MM:SS' format for large hours values). TIME values may range from
 '-838:59:59' to '838:59:59'. The hours part may be so large because the
 TIME type can be used not only to represent a time of day (which must be
 less than 24 hours), but also elapsed time or a time interval between two
 events (which may be much greater than 24 hours, or even negative)."

 http://dev.mysql.com/doc/refman/5.0/en/time.html

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17764: Documentation out-of-date: django.contrib.auth.utils no longer exists.

[Django]

#17764: Documentation out-of-date: django.contrib.auth.utils no longer exists.
-+-
 Reporter:  mbt  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:   |Version:  1.4-beta-1
  Documentation  |   Keywords:  authentication documentation  easy-
 Severity:  Release  |  pickings
  blocker|  Has patch:  0
 Triage Stage:   |  UI/UX:  0
  Unreviewed |
Easy pickings:  1|
-+-
 https://docs.djangoproject.com/en/dev/topics/auth/ in the “Manually
 managing a user’s password” section, a reference is made to the
 django.contrib.auth.utils module, but this module does not exist.  It was
 created in response to #14390 in SVN r16456 (or git a51a059899) in June
 2011) but then six months later in SVN r17254 (or git 0516dc6741) it was
 moved to the django.contrib.auth.hashers module.

 The documentation shows that this was added for “the development release”,
 which I assume means the Django 1.4 development cycle, so it should not
 affect older versions of Django or its documentation.

 I _may_ be able to provide a simple patch in a git tree later, depending
 on how my schedule for today goes, but I wanted to get this reported so
 that it was known before the Django 1.4 series enters the next iteration
 of its release process.

 I am marking this as a release blocker based on the rationale that:

  * this is not a regression and is a defect in documentation for the new
 release; and
  * it is a relatively easy defect to fix; and
  * the outdated documentation can easily cost someone an hour of time
 tracking down a “problem” that does not exist.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17760: connection.features.supports_transactions is None

[Django]

#17760: connection.features.supports_transactions is None
-+-
 Reporter:  cdestigter   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * stage:  Unreviewed => Accepted


Comment:

 I just translated akaariai's comment:2 into a patch. Not sure if something
 should be tested here.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17763: Problem with auth_permission name length

[Django]

#17763: Problem with auth_permission name length
--+
 Reporter:  stenius@… |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.auth  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 Django automatically generates a name that is longer than what the default
 field length can hold.


 {{{INSERT INTO "auth_permission" ("name", "content_type_id", "codename")
 VALUES (%s, %s, %s) (u'Can add study plan practice assessment tutorial
 question', 52, u'add_studyplanpracticeassessmenttutorialquestion')}}}

 This will fail with a error about it not being able to fit in a
 varchar(50)
 {{{
  Table "public.auth_permission"
  Column  |  Type  |
 Modifiers
 
-++--
  id  | integer| not null default
 nextval('auth_permission_id_seq'::regclass)
  name| character varying(50 ) | not null
  content_type_id | integer| not null
  codename| character varying(100) | not null
 }}}
 This was under PostgreSQL and after modifying the field to have a length
 of 200, I was able to perform the insert.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17759: FormMixin instantiates form with dict stored on the class

[Django]

#17759: FormMixin instantiates form with dict stored on the class
---+--
 Reporter:  agriffis   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Generic views  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by claudep):

 * needs_tests:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17760: connection.features.supports_transactions is None

[Django]

#17760: connection.features.supports_transactions is None
-+-
 Reporter:  cdestigter   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 I think the connection.features.supports_transactions should be a cached
 property. It checks the support when first accessed, later on it is just a
 normal boolean. That way there would be no need to run features.confirm()
 at all, supports transactions is always usable.

 I haven't verified the issue, so the above is more a general note...

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15169: With gis.mysql backend BooleanField convert to Python as 1|0 instead of True|False

[Django]

#15169: With gis.mysql backend BooleanField convert to Python as 1|0 instead of
True|False
+
 Reporter:  zmsmith |Owner:  jbronn
 Type:  Bug |   Status:  assigned
Component:  GIS |  Version:  1.2
 Severity:  Release blocker |   Resolution:
 Keywords:  BooleanField, GIS,  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by carljm):

 * severity:  Normal => Release blocker


Comment:

 Marking this as a release blocker, since in combination with r17132 it is
 effectively a serious regression in 1.4 (see #17747, closed as duplicate).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17758: Do not depend on dict order in test suite

[Django]

#17758: Do not depend on dict order in test suite
-+
 Reporter:  lrekucki |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by carljm):

 * component:  Uncategorized => Core (Other)
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Attribute order in HTML output should have been addressed by r17414 - if
 some cases were missed, `assertHTMLEqual` ought to make the fix simple in
 those cases.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17747: BooleanField on ModelForms in ModelAdmin is always True

[Django]

#17747: BooleanField on ModelForms in ModelAdmin is always True
-+-
 Reporter:  Cochise Ruhulessin   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:
 Severity:  Release blocker  |  1.4-beta-1
 Keywords:  booleanfield,|   Resolution:  duplicate
  modelform, modeladmin  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by carljm):

 * status:  reopened => closed
 * resolution:   => duplicate


Comment:

 Replying to [comment:7 aaugustin]:
 > IMO the database backends should return the most appropriate type under
 all circumstances — here, booleans.
 >
 > Loose typing in the ORM leads to backwards-compatibility headaches and
 problems with no good solution, like the datetime/date can of worms.

 Agreed. And given that returning 0/1 for boolean values in built-in DB
 backends has long been considered a bug in that backend, I no longer even
 think this justifies a note in the release notes. Closing this as a
 duplicate of #15169.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17747: BooleanField on ModelForms in ModelAdmin is always True

[Django]

#17747: BooleanField on ModelForms in ModelAdmin is always True
-+-
 Reporter:  Cochise Ruhulessin   |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Forms|  Version:
 Severity:  Release blocker  |  1.4-beta-1
 Keywords:  booleanfield,|   Resolution:
  modelform, modeladmin  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by aaugustin):

 IMO the database backends should return the most appropriate type under
 all circumstances — here, booleans.

 Loose typing in the ORM leads to backwards-compatibility headaches and
 problems with no good solution, like the datetime/date can of worms.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17747: BooleanField on ModelForms in ModelAdmin is always True

[Django]

#17747: BooleanField on ModelForms in ModelAdmin is always True
-+-
 Reporter:  Cochise Ruhulessin   |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Forms|  Version:
 Severity:  Release blocker  |  1.4-beta-1
 Keywords:  booleanfield,|   Resolution:
  modelform, modeladmin  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by carljm):

 It looks like #15169 is already tracking the root problem in the db
 backend. So the only remaining question for this ticket is whether it's
 acceptable to now require that db backends return `True`/`False` from
 boolean fields in order for checkboxes in a `ModelForm` to work correctly.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17747: BooleanField on ModelForms in ModelAdmin is always True

[Django]

#17747: BooleanField on ModelForms in ModelAdmin is always True
-+-
 Reporter:  Cochise Ruhulessin   |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Forms|  Version:
 Severity:  Release blocker  |  1.4-beta-1
 Keywords:  booleanfield,|   Resolution:
  modelform, modeladmin  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by carljm):

 For reference from that thread, r17132 was the relevant change in checkbox
 handling in 1.4. r12939 may be the earlier fix that needs to be ported to
 the MySQL GIS backend (though I'm not sure if that's right, it claims to
 only be related to use of `.extra()`).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17747: BooleanField on ModelForms in ModelAdmin is always True

[Django]

#17747: BooleanField on ModelForms in ModelAdmin is always True
-+-
 Reporter:  Cochise Ruhulessin   |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Forms|  Version:
 Severity:  Release blocker  |  1.4-beta-1
 Keywords:  booleanfield,|   Resolution:
  modelform, modeladmin  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by carljm):

 * status:  closed => reopened
 * resolution:  worksforme =>
 * component:  Uncategorized => Forms


Comment:

 There's a [https://groups.google.com/forum/?fromgroups#!topic/django-
 developers/fYlbL1_J70s thread on the django-developers list] indicating
 that perhaps this bug exists only on MySQL, and perhaps only on the MySQL
 GIS backend. I don't have time to verify at this moment (don't have MySQL
 GIS set up), but to be on the safe side I'm going to reopen this (and mark
 it as a release blocker, since apparently the symptom in form checkboxes
 is a regression from 1.3) until I have time to reproduce.

 Setting the component to "forms", although if the mailing list thread is
 correct, it sounds like the correct fix here may in fact be in the MySQL
 GIS backend, so that it returns `True`/`False` rather than 1/0 from the
 database.

 We'd also need to consider whether the checkbox change in 1.4 is itself a
 problematic backwards incompatibility, since in effect it now requires
 third-party DB backends to return `True`/`False` from boolean fields
 rather than 1/0. I don't know if in practice there are any third-party db
 backends that return 1/0.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6851: Documentation erroneously states TEMPLATE_CONTEXT_PROCESSORS are set

[Django]

#6851: Documentation erroneously states TEMPLATE_CONTEXT_PROCESSORS are set
---+--
 Reporter:  roderikk@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by carljm):

 * status:  reopened => closed
 * resolution:   => invalid


Comment:

 All of the built-in settings have global defaults, which are the effective
 value of the setting if the setting doesn't appear in your own settings
 file. ``TEMPLATE_CONTEXT_PROCESSORS`` does have the default value that it
 is documented to have, if that value isn't overridden in your own settings
 file.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6851: Documentation erroneously states TEMPLATE_CONTEXT_PROCESSORS are set

[Django]

#6851: Documentation erroneously states TEMPLATE_CONTEXT_PROCESSORS are set
---+--
 Reporter:  roderikk@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  reopened
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by anonymous):

 * status:  closed => reopened
 * severity:   => Normal
 * type:   => Uncategorized
 * easy:   => 0
 * ui_ux:   => 0
 * resolution:  invalid =>


Comment:

 The documentation does state that there is a non-empty default value for
 this setting:

 ("django.contrib.auth.context_processors.auth",
 "django.core.context_processors.debug",
 "django.core.context_processors.i18n",
 "django.core.context_processors.media",
 "django.core.context_processors.static",
 "django.contrib.messages.context_processors.messages")

 Here:

 https://docs.djangoproject.com/en/1.3/ref/templates/api/#subclassing-
 context-requestcontext

 and here:

 https://docs.djangoproject.com/en/1.3/ref/settings/#template-context-
 processors

 Isn't this wrong? I don't see any context processors in my settings.py
 files.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17760: connection.features.supports_transactions is None

[Django]

#17760: connection.features.supports_transactions is None
-+-
 Reporter:  cdestigter   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by cdestigter):

 * needs_docs:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 initial fix:
 
https://github.com/koordinates/django/commit/66de288e80377e645369d56e44fcdb02dbed0276

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17762: Multi-db testing fails to create multiple databases

[Django]

#17762: Multi-db testing fails to create multiple databases
--+
 Reporter:  agriffis  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 When testing a project with multiple databases, Django fails to create
 multiple in-memory SQLite databases, instead it creates only one (which is
 populated only with the table definitions for the default DB).  The
 problem is that the generic test_db_signature() in
 [source:django/trunk/django/db/backends/creation.py
 db/backends/creation.py] doesn't work for in-memory SQLite databases,
 which all have the same NAME (":memory:").

 The attached patch fixes this problem by adding a test_db_signature()
 method to the SQLite DatabaseCreation class.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14039: FileField special-casing breaks MultiValueField including a FileField

[Django]

#14039: FileField special-casing breaks MultiValueField including a FileField
---+
 Reporter:  carljm |Owner:  carljm
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords:  sprintSep2010  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by carljm):

 Replying to [comment:10 valexeev]:
 > What's the status of this bug? Is there any work needed to be done so it
 finally makes it in a release?

 The "needs documentation" flag is set. That means the patch needs to
 include updates to the documentation, and currently doesn't.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17761: save_base() does not properly detect when MTI parent key is unset

[Django]

#17761: save_base() does not properly detect when MTI parent key is unset
-+-
 Reporter:  agriffis |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by agriffis):

 * cc: aron@… (added)
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_better_patch:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17761: save_base() does not properly detect when MTI parent key is unset

[Django]

#17761: save_base() does not properly detect when MTI parent key is unset
--+
 Reporter:  agriffis  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Consider the following MTI scenario, where the primary key of the parent
 is a !CharField:

 {{{
 #!python

 from django.db import models

 class Foo(models.Model):
 id = models.CharField(max_length=6, primary_key=True)

 class Bar(Foo):
 data = models.TextField()
 }}}

 Attempting to instantiate and save the child model fails:

 {{{
 >>> from bar.models import Bar
 >>> b=Bar()
 >>> b.pk='abcdef'
 >>> b.save()
 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/aron/.virtualenvs/pp/lib/python2.7/site-
 packages/django/db/models/base.py", line 460, in save
 self.save_base(using=using, force_insert=force_insert,
 force_update=force_update)
   File "/home/aron/.virtualenvs/pp/lib/python2.7/site-
 packages/django/db/models/base.py", line 553, in save_base
 result = manager._insert(values, return_id=update_pk, using=using)
   File "/home/aron/.virtualenvs/pp/lib/python2.7/site-
 packages/django/db/models/manager.py", line 195, in _insert
 return insert_query(self.model, values, **kwargs)
   File "/home/aron/.virtualenvs/pp/lib/python2.7/site-
 packages/django/db/models/query.py", line 1436, in insert_query
 return query.get_compiler(using=using).execute_sql(return_id)
   File "/home/aron/.virtualenvs/pp/lib/python2.7/site-
 packages/django/db/models/sql/compiler.py", line 791, in execute_sql
 cursor = super(SQLInsertCompiler, self).execute_sql(None)
   File "/home/aron/.virtualenvs/pp/lib/python2.7/site-
 packages/django/db/models/sql/compiler.py", line 735, in execute_sql
 cursor.execute(sql, params)
   File "/home/aron/.virtualenvs/pp/lib/python2.7/site-
 packages/django/db/backends/util.py", line 34, in execute
 return self.cursor.execute(sql, params)
   File "/home/aron/.virtualenvs/pp/lib/python2.7/site-
 packages/django/db/backends/sqlite3/base.py", line 234, in execute
 return Database.Cursor.execute(self, query, params)
 IntegrityError: bar_bar.foo_ptr_id may not be NULL
 }}}

 The reason this happens is the following code around line 500 in
 [source:django/trunk/django/db/models/base.py db/models/base.py]:

 {{{
 #!python
 class Model(object):
 ...

 def save_base(...):
 ...

 for parent, field in meta.parents.items():
 # At this point, parent's primary key field may be unknown
 # (for example, from administration form which doesn't fill
 # this field). If so, fill it.
 if field and getattr(self, parent._meta.pk.attname) is None
 and getattr(self, field.attname) is not None:
 setattr(self, parent._meta.pk.attname, getattr(self,
 field.attname))

 self.save_base(cls=parent, origin=org, using=using)
 }}}

 This fails because the default value for a !CharField is the emtpy string
 rather than None. This code works for an !IntegerField primary key (which
 defaults to None until set).  It also works for a !CharField(null=True)
 but
 it's not clear to me that's the right answer, because it means null is
 valid for the DB column, which isn't right.

 I ''think'' the right answer is to change the test from "is None" to "in
 [None, !'']" as shown in the attached patch.

 You might ask, "What about the test on the child model's pk? Does that
 need
 to change too?" The answer is no, because the child model's pk is a
 !OneToOneField which defaults to None, so only the first None-test on the
 line needs to change.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17759: FormMixin instantiates form with dict stored on the class

[Django]

#17759: FormMixin instantiates form with dict stored on the class
---+--
 Reporter:  agriffis   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Generic views  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by agriffis):

 * type:  Uncategorized => Bug


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17760: connection.features.supports_transactions is None

[Django]

#17760: connection.features.supports_transactions is None
--+
 Reporter:  cdestigter|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Background: To speed up our tests we have a custom nose-based test runner
 which *doesn't* drop/create the database. It shouldn't need to when tests
 are run in a transaction. This prevents us having to load fixtures etc, as
 most of the test data lives permanently in the database.

 However after upgrading to django 1.3,
 `connection.features.supports_transactions` is always None, causing our
 tests to use TRUNCATEs instead of transactions.

 This appears to be because connection.features.confirm() is only called
 from create_test_db():
 
https://code.djangoproject.com/browser/django/tags/releases/1.3/django/db/backends/creation.py#L357

 I'd argue that's the wrong place to do it. It should probably happen when
 the connection is first initialised, or at least in
 `TestCase._pre_setup()`

 This has caused issues before: #16622 #16885 (possibly others)

 (To be fair it shouldn't really be on connection.features at all, since
 it's only set during testing and is otherwise always None)

 Tested with 1.3.1 and master.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17759: FormMixin instantiates form with dict stored on the class

[Django]

#17759: FormMixin instantiates form with dict stored on the class
---+--
 Reporter:  agriffis   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Generic views  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by agriffis):

 * cc: aron@… (added)
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_better_patch:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17759: FormMixin instantiates form with dict stored on the class

[Django]

#17759: FormMixin instantiates form with dict stored on the class
---+
 Reporter:  agriffis   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Generic views  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Consider the following form:

 {{{
 #!python
 class MyForm(ModelForm):
   def __init__(self, *args, **kwargs):
 kwargs['initial']['foo'] = 'bar'
 super(MyForm, self).__init__(*args, **kwargs)
 }}}

 When used with Django's class-based generic views, this will cause all
 following form instantiations to have a default `initial` dict with the
 content `{'foo': 'bar'}` because the dict is inadvertently updated on the
 class.

 The problem is the following code in
 [source:django/trunk/django/views/generic/edit.py generic/edit.py]:

 {{{
 #!python
 class FormMixin(object):
 initial = {}

 def get_initial(self):
 return self.initial

 def get_form_kwargs(self):
 kwargs = {'initial': self.get_initial()}
 ...
 }}}

 I think the right fix here is to shallow-copy the dict in get_initial,
 will attach patch.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #2594: Template system should handle whitespace better

[Django]

#2594: Template system should handle whitespace better
-+-
 Reporter:  Gary Wilson  |Owner:  jshedd
  |   Status:  new
 Type:  Bug  |  Version:  SVN
Component:  Template system  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by tobia):

 I just started a thread about an alternative solution to this problem.

 Newline stripping in templates: the dnl way

 http://groups.google.com/group/django-
 developers/browse_thread/thread/8d6b6a3aae82ee03

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17758: Do not depend on dict order in test suite

[Django]

#17758: Do not depend on dict order in test suite
-+
   Reporter:  lrekucki   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  1.3
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 This includes things like attribute order in HTML output, key order in URL
 query strings, order in Form's {{{error}}}, etc.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17497: Confusing exception message when using values_list with relations

[Django]

#17497: Confusing exception message when using values_list with relations
-+-
 Reporter:  ojii |Owner:
 Type:   |  antoviaque
  Cleanup/optimization   |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ojii):

 * stage:  Accepted => Ready for checkin


Comment:

 I would say better error messages for ``extra`` could be a separate
 ticket. The supplied patch applied cleanly to trunk and tests passed. Also
 manually checked that the output is what I would expect. LGTM.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
 Reporter:  xkennyx@…|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  cascade delete   |  Needs documentation:  0
  proxy meta |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by anler ):

 Replying to [comment:28 anonymous]:
 > That was me, I submitted it as anonymous again, accidentally

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
 Reporter:  xkennyx@…|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  cascade delete   |  Needs documentation:  0
  proxy meta |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by anonymous):

 Sorry, I resolve it as fixed accidentally :S Regarding the tests, I repeat
 what I said before, the tests pass...sometimes and sometimes doesn't,
 without change nothing! It's pretty rare, but I'm posting it here just in
 case it happens to someone else.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13614: Back button breaks many to many widget

[Django]

#13614: Back button breaks many to many widget
-+
 Reporter:  minarets |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  contrib.admin|  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+

Comment (by julien):

 The patch above gets around the Chrome bug. However, the tests also
 highlight another bug in... Firefox :-/

 In Firefox, if you select some options, then navigate away and go back,
 the options get reinitialized to their original values.

 This is driving me insane :-)  Some manual testing on other browsers and
 platforms would be welcome. Thanks!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17754: Django GIS Measure refactor

[Django]

#17754: Django GIS Measure refactor
--+
 Reporter:  riccardodivirgilio|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by riccardodivirgilio):

 please wait that i'll post a new version. there are some algebric issue
 with this class.

 with this class you can't divide Measure with Measure, but in math this is
 wrong...

 3m * 3m = (3*3) * (m *m) = 9m^2
 3m / 3m = (3/3) * (m/m) = 1

 i'll attach a new version that support __div__ with other instance of the
 same class

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17750: User.get_profile() returns cached object when database object has changed

[Django]

#17750: User.get_profile() returns cached object when database object has 
changed
--+
 Reporter:  rjalves   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 Thanks for the doc part. But please, merge both patches into one.

 You are right in that we cannot create new models for contrib tests, so I
 think we should create a new test directory in
 tests/regressiontests/user_profile/...

 In the documentation, you should also add the "{{{.. versionchanged::
 1.5}}}" mark to indicate this was a new addition (as a new feature, it
 will be too late to be included in 1.4).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.