Re: [Django] #6027: FileWrapper iterator drained by GzipMiddleware before content can be returned

[Django]

#6027: FileWrapper iterator drained by GzipMiddleware before content can be
returned
--+
 Reporter:  volsung@… |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  SVN
 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
--+

Comment (by grahamd):

 As well as FileWrapper issue where first use of request.content will
 consume it and not available on second use, you also have case where
 someone is defining a custom iterable with __iter__ which does properly
 restart. In this case if the iteration is an expensive operation, ie.,
 generating data on the fly from an operation triggered on each __iter__
 call to create actual iterable, then you end up doing the expensivee
 operation more than once. Arguable that response.content could cache the
 result within the HttpResponse object when generated. The issue there is
 obviously that people wanted to use an iterable to avoid having it all in
 memory.

-- 
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] #18117: Django 1.4 Trouble Creating Large Numbers of Tables with SQLite

[Django]

#18117: Django 1.4 Trouble Creating Large Numbers of Tables with SQLite
---+-
 Reporter:  rball@…|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:  SQLite, max columns
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+-
 After upgrading from Django 1.3 to Django 1.4 and running syncdb I get the
 following error message (with traceback):

 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/core/management/__init__.py", line
 443, in execute_from_command_line
 utility.execute()
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/core/management/__init__.py", line
 382, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/core/management/base.py", line 196,
 in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/core/management/base.py", line 232,
 in execute
 output = self.handle(*args, **options)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/core/management/base.py", line 371,
 in handle
 return self.handle_noargs(**options)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/core/management/commands/syncdb.py",
 line 110, in handle_noargs
 emit_post_sync_signal(created_models, verbosity, interactive, db)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/core/management/sql.py", line 189, in
 emit_post_sync_signal
 interactive=interactive, db=db)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/dispatch/dispatcher.py", line 172, in
 send
 response = receiver(signal=self, sender=sender, **named)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/contrib/auth/management/__init__.py",
 line 54, in create_permissions
 auth_app.Permission.objects.bulk_create(objs)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/db/models/manager.py", line 140, in
 bulk_create
 return self.get_query_set().bulk_create(*args, **kwargs)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/db/models/query.py", line 410, in
 bulk_create
 self.model._base_manager._insert(objs, fields=fields, using=self.db)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/db/models/manager.py", line 203, in
 _insert
 return insert_query(self.model, objs, fields, **kwargs)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/db/models/query.py", line 1576, in
 insert_query
 return query.get_compiler(using=using).execute_sql(return_id)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/db/models/sql/compiler.py", line 910,
 in execute_sql
 cursor.execute(sql, params)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/db/backends/util.py", line 40, in
 execute
 return self.cursor.execute(sql, params)
   File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4-py2.7.egg/django/db/backends/sqlite3/base.py", line
 337, in execute
 return Database.Cursor.execute(self, query, params)
 django.db.utils.DatabaseError: too many SQL variables

 After doing some research I discovered that this error message is
 frequently related to trying to create more columns than the sqlite
 configuration file is set to allow (2000 by default, see
 http://www.sqlite.org/limits.html). I don't have any one table with more
 than 2000 columns but all the tables together have well over that amount.
 It seems this may be a bug and I haven't seen anyone else mention this as
 a problem.

 When I reduce the number of tables in my models.py to well below 2000 the
 models are all created just 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] #18115: Warn that repeated "setup.py install" without removal causes problems

[Django]

#18115: Warn that repeated "setup.py install" without removal causes problems
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by kmtracey):

 We did used to note that you had to get rid of any old install before re-
 install: https://docs.djangoproject.com/en/1.0/topics/install/#remove-any-
 old-versions-of-django

 Not that everyone read/did that (possibly because the instructions were
 not exactly specific, since there wasn't any official way to
 "uninstall"?), leading to tickets like #9090 and #9112.

 But we should definitely put a note back around instructions to use
 setup.py that if you've already got Django installed it needs to be
 removed first before you run setup.py again. Possibly a stronger note than
 used to be there.

-- 
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] #18116: Drop support for older MySQL versions

[Django]

#18116: Drop support for older MySQL versions
-+-
   Reporter:  ramiro |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |Version:  SVN
  Component:  Database   |   Keywords:
  layer (models, ORM)|  Has patch:  0
   Severity:  Normal |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 The idea is to drop support of MySQL 4.x (and perhaps 5.0?) for Django
 1.5. See:


 - [http://www.mysql.com/support/eol-notice.html MySQL Product Support EOL
 Announcements]
 - [http://www.mysql.com/support/supportedplatforms/database.html Supported
 Platforms: MySQL Database]
 - [http://www.mysql.com/support/ MySQL Technical Support]

 The first document list the following relevant dates:

 * January 9, 2012 -- Per Oracle's Lifetime Support policy, MySQL 5.0 is
 now covered under Oracle Sustaining Support.

 * December 31, 2009 -- Per the MySQL Support Lifecycle policy, extended
 support for MySQL 4.1 ended on December 31, 2009. MySQL users are
 encouraged to upgrade to a current production release of MySQL. Customers
 needing upgrade assisitance should contact MySQL Support.

 * December 31, 2009 -- Per the MySQL Support Lifecycle policy, active
 support for MySQL 5.0 ended on December 31, 2009. MySQL 5.0 is now in the
 Extended support phase.

-- 
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] #18115: Warn that repeated "setup.py install" without removal causes problems

[Django]

#18115: Warn that repeated "setup.py install" without removal causes problems
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 Please add a note how to detect Django version and path:


 {{{
 >>> import django
 >>> django.VERSION
 (1, 3, 0, 'final', 0)
 >>> django.__file__
 '/home/lucianopacheco/src/tmp_py/local/lib/python2.7/site-
 packages/django/__init__.pyc'
 }}}


 So, it will be much more clear to people not familiar with python
 installation structure to understand what "site-packages" means.

-- 
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] #18115: Warn that repeated "setup.py install" without removal causes problems

[Django]

#18115: Warn that repeated "setup.py install" without removal causes problems
+
   Reporter:  carljm|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  1.4
   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 |
+
 If you repeatedly install newer versions of Django (or any other Python
 project) using "python setup.py install", without removing the previously-
 installed version, any files removed in the newer version will never be
 removed from your site-packages. This can potentially cause a variety of
 problems, including imports continuing to "work" (with outdated code) that
 ought to fail, and most visibly in Django 1.4, extraneous files in the
 startproject template.

 The installation instructions ought to include a clear warning against
 this. Currently there's a bit of a warning at the end of
 [https://docs.djangoproject.com/en/dev/topics/install/#installing-an-
 official-release-manually this section], but it's not as clear as it could
 be about the specific risk of repeated "setup.py install", and it's in the
 section about installing using a pth file or symbolic link, which is a
 different thing entirely.

-- 
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] #18031: Subclassing a model field: call_with_connection_and_prepared bug

[Django]

#18031: Subclassing a model field: call_with_connection_and_prepared bug
-+-
 Reporter:  smbrooks1@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  Custom Field,|  Unreviewed
  get_db_prep_value  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * status:  new => closed
 * needs_docs:   => 0
 * resolution:   => wontfix
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 Thanks for the report, but this is now old code, and unless there are
 serious security implications, I'm afraid we won't touch it any more.
 Sorry. Reopen if you can reproduce the bug with recent code.

-- 
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] #18111: Django autoreload doesn't work for forms.py or tests.py in my app (but does for models.py)

[Django]

#18111: Django autoreload doesn't work for forms.py or tests.py in my app (but 
does
for models.py)
---+--
 Reporter:  stu.axon@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:  invalid
 Keywords:  autoreload | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by aaugustin):

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


Comment:

 By design, the development server only reloads code that it's actually
 using.

 If forms.py isn't used, what's the point in reloading the development
 server when it's changed?

-- 
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] #18096: Overiding delete permissions in the Admin

[Django]

#18096: Overiding delete permissions in the Admin
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by anonymous):

 Yes this was a typo, has_delete_permission is the method. The default
 implementation calls opts.get_delete_permission(). The point that
 regardless of what you say in has_delete_permission the check in
 opt.get_delete_permission must pass otherwise the delete will not be
 allowed is still valid.

-- 
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] #18114: makemessages does not care about context in trans templatetag

[Django]

#18114: makemessages does not care about context in trans templatetag
-+-
 Reporter:  tomaz.stucin@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Translations |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  trans context,   | Triage Stage:
  pgettext   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by julien):

 Thanks for the report, however I cannot reproduce your issue (see the
 attached test case). Are you able to provide a test case for Django that
 highlights the problem?

-- 
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] r17904 - in django/trunk: django/db/models/fields tests/regressiontests/many_to_one_regress

[noreply]

Author: claudep
Date: 2012-04-12 13:23:41 -0700 (Thu, 12 Apr 2012)
New Revision: 17904

Modified:
   django/trunk/django/db/models/fields/related.py
   django/trunk/tests/regressiontests/many_to_one_regress/tests.py
Log:
Fixed #18002 -- Fixed typo in attribute name in 
ReverseSingleRelatedObjectDescriptor.


Modified: django/trunk/django/db/models/fields/related.py
===
--- django/trunk/django/db/models/fields/related.py 2012-04-12 16:35:28 UTC 
(rev 17903)
+++ django/trunk/django/db/models/fields/related.py 2012-04-12 20:23:41 UTC 
(rev 17904)
@@ -364,7 +364,7 @@
 
 def __set__(self, instance, value):
 if instance is None:
-raise AttributeError("%s must be accessed via instance" % 
self._field.name)
+raise AttributeError("%s must be accessed via instance" % 
self.field.name)
 
 # If null=True, we can assign null here, but otherwise the value needs
 # to be an instance of the related class.

Modified: django/trunk/tests/regressiontests/many_to_one_regress/tests.py
===
--- django/trunk/tests/regressiontests/many_to_one_regress/tests.py 
2012-04-12 16:35:28 UTC (rev 17903)
+++ django/trunk/tests/regressiontests/many_to_one_regress/tests.py 
2012-04-12 20:23:41 UTC (rev 17904)
@@ -58,6 +58,10 @@
 self.assertRaises(ValueError, Child, name='xyzzy', parent=None)
 self.assertRaises(ValueError, Child.objects.create, name='xyzzy', 
parent=None)
 
+# Trying to assign to unbound attribute raises AttributeError
+self.assertRaisesRegexp(AttributeError, "must be accessed via 
instance",
+Child.parent.__set__, None, p)
+
 # Creation using keyword argument should cache the related object.
 p = Parent.objects.get(name="Parent")
 c = Child(parent=p)

-- 
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] #18002: Typo in ReverseSingleRelatedObjectDescriptor

[Django]

#18002: Typo in ReverseSingleRelatedObjectDescriptor
-+-
 Reporter:  Bradley Ayers|Owner:  nobody
|   Status:  closed
 Type:  Bug  |  Version:  1.4
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-
Changes (by claudep):

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


Comment:

 In [17904]:
 {{{
 #!CommitTicketReference repository="" revision="17904"
 Fixed #18002 -- Fixed typo in attribute name in
 ReverseSingleRelatedObjectDescriptor.
 }}}

-- 
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] #18114: makemessages does not care about context in trans templatetag

[Django]

#18114: makemessages does not care about context in trans templatetag
-+-
 Reporter:  tomaz.stucin@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Translations |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  trans context,   | Triage Stage:
  pgettext   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by tomaz.stucin@…):

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


Comment:

 sorry, there is a typo in my report: in my code it is not:
 {{{
 {trans ...
 }}}
 but it is:
 {% trasn ...
 }}}

 so this is definitely not the problem.

-- 
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] #18114: makemessages does not care about context in trans templatetag

[Django]

#18114: makemessages does not care about context in trans templatetag
+-
 Reporter:  tomaz.stucin@…  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Translations|Version:  1.4
 Severity:  Normal  |   Keywords:  trans context, pgettext
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+-
 We are working with translations and we have done the following
 * we have 2 templates: template1.html and template2.html
 * in template1 we have the following:
 {{{
 {trans 'contact' as trans_contact %}
 }}}
 * in template2 we have the following:
 {{{
 {trans 'contact' context 'suggestive' as trans_contact %}
 }}}
 * when we makemessages -a we get the following in the django.po file:
 {{{
 #: web/templates/web/template1.html:35
 #: web/templates/web/template2.html:21
 msgid "contact"
 msgstr ""
 }}}
 - what we expect instead (in django.po) is actually:
 {{{
 #: web/templates/web/template1.html:35
 msgid "contact"
 msgstr ""
 #: web/templates/web/template2.html:21
 msgctxt "suggesttive"
 msgid "contact"
 msgstr ""
 }}}

 So it seems that the "django-admin.py makemessages -a" does not take into
 account context in the trans templatetag (but it does process both trans
 tag as can be seen in the comment)

 If we write (anywhere in the code) the following:
 {{{
 from django.utils.translation import pgettext
 test = pgettext('suggesttive', 'contact')
 }}}

 then the django.po content is as expected and if we translate the strings
 (in django.po) and then render the template, the context is taken into
 account and the translation on the webpage (produced from the template) is
 as it should be, so the trans templatetag works as expected, just the
 makemessages does not.


 If this is a "feature" I apologize in advance.

-- 
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] #18100: Deleting model instances with deferred fields don't trigger deletion signals

[Django]

#18100: Deleting model instances with deferred fields don't trigger deletion
signals
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  deferred delete  |  Needs documentation:  0
  signals|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by carljm):

 Replying to [comment:5 charettes]:
 > Even if #9318 is fixed we wan't to avoid dispatching signals for the
 `DeferredFieldProxy` for performance reasons.
 >
 > Anyway what's the use case of dispatching it since no one can really
 subscribe? IMHO we should really avoid doing so.

 There's not a use case for it, clearly, but there is code-maintainability
 value in not having to think about this special case whenever we fire
 model signals.

 The performance concern is relevant if #9318 is fixed by firing signals
 multiple times (in that case I agree that we should fix this), but not if
 it's fixed in the signals framework itself, to fire the signal only once
 but include superclass receivers.

 I don't feel strongly about _not_ doing this, but I do think that if we do
 fix it, we should fix it consistently for all model signals.

-- 
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] #18100: Deleting model instances with deferred fields don't trigger deletion signals

[Django]

#18100: Deleting model instances with deferred fields don't trigger deletion
signals
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  deferred delete  |  Needs documentation:  0
  signals|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by charettes):

 Even if #9318 is fixed we wan't to avoid dispatching signals for the
 `DeferredFieldProxy` for performance reasons.

 Anyway what's the use case of dispatching it since no one can really
 subscribe? IMHO we should really avoid doing so.

-- 
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] #18100: Deleting model instances with deferred fields don't trigger deletion signals

[Django]

#18100: Deleting model instances with deferred fields don't trigger deletion
signals
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  deferred delete  |  Needs documentation:  0
  signals|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by carljm):

 Hmm, I'm still not convinced that this fix makes sense. The fact that
 deferred/only use a proxy model is something that can't be made
 transparent to the user (a simple check of the class of the returned model
 instances will reveal it), so I'm not sure there's any point to adding
 extra complexity to the code just to try to hide it in this one case. (I'm
 not sure that proxy models should have been used for deferred/only, but
 that's water under the bridge now.)

 The real problem here is that receivers registered for the superclass
 currently won't run, but IMO the right fix for that is to fix #9318.

 Contrary to akaariai, if we do decide to implement this special-case fix,
 I don't think there's any compelling reason not to fix it for all the
 model signals at once.

-- 
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] #18113: Class based view mixin docstrings reference incorrect method

[Django]

#18113: Class based view mixin docstrings reference incorrect method
-+--
 Reporter:  Keryn Knight   |  Owner:  nobody
 Type:  Cleanup/optimization | Status:  new
Component:  Documentation|Version:  SVN
 Severity:  Normal   |   Keywords:  get_template CBV
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+--
 Both the SingleObjectTemplateResponseMixin and the
 MultipleObjectTemplateResponseMixin (detail and list, respectively) have
 the following docstring for the method get_template_names()
 {{{
 Return a list of template names to be used for the request. Must return
 a list. May not be called if get_template is overridden.
 }}}
 However, looking through all the generic views, and grepping SVN trunk, I
 can't find anywhere get_template itself is being defined, or used.  The
 closest thing I can find is the legacy form wizard having that method.

-- 
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] #18112: contrib.syndication.views: Add hook for getting extra context in feed templates

[Django]

#18112: contrib.syndication.views: Add hook for getting extra context in feed
templates
-+-
 Reporter:  slinkp   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.syndication  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by slinkp):

 * needs_better_patch:   => 0
 * type:  Uncategorized => New feature
 * 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] #9318: "Virtual" behaviour for signal dispatcher and model inheritance

[Django]

#9318: "Virtual" behaviour for signal dispatcher and model inheritance
-+-
 Reporter:  svetlyak40wt |Owner:  jdunck
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  1.0
 Severity:  Normal   |   Resolution:
 Keywords:  model inheritance,   | Triage Stage:  Accepted
  signals, dispatch, proxy,  |  Needs documentation:  0
  subclass   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  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.

Re: [Django] #9318: "Virtual" behaviour for signal dispatcher and model inheritance

[Django]

#9318: "Virtual" behaviour for signal dispatcher and model inheritance
-+-
 Reporter:  svetlyak40wt |Owner:  jdunck
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  1.0
 Severity:  Normal   |   Resolution:
 Keywords:  model inheritance,   | Triage Stage:  Accepted
  signals, dispatch, proxy,  |  Needs documentation:  0
  subclass   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by streeter):

 * cc: streeter (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.

Re: [Django] #18094: `pre_delete` and `post_delete` signals are not correctly sent in inheritance scenarios involving proxy models

[Django]

#18094: `pre_delete` and `post_delete` signals are not correctly sent in
inheritance scenarios involving proxy models
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:  model proxy multi-   |  Unreviewed
  table inheritance signals delete   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by streeter):

 * cc: streeter (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.

Re: [Django] #9318: "Virtual" behaviour for signal dispatcher and model inheritance

[Django]

#9318: "Virtual" behaviour for signal dispatcher and model inheritance
-+-
 Reporter:  svetlyak40wt |Owner:  jdunck
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  1.0
 Severity:  Normal   |   Resolution:
 Keywords:  model inheritance,   | Triage Stage:  Accepted
  signals, dispatch, proxy,  |  Needs documentation:  0
  subclass   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by carljm):

 Replying to [comment:20 carljm]:
 > I'll also repeat one comment I made on #18094: I think a fix that relies
 on opt-in from the person registering the signal handler is not adequate,
 as this is often not the same person who might be creating a subclass
 (particularly a proxy subclass). A reusable app that registers a signal
 handler for a model ought to be able to assume that that handler will fire
 when instances of that model are involved, without needing to take special
 opt-in steps to ensure that this is still the case when subclasses are
 involved.

 Although I suppose that this might be a necessary concession to backwards
 compatibility - in that case, it should be featured in the documentation,
 as I would think that most new code should register signal handlers using
 this new opt-in flag (and perhaps we should even consider deprecating the
 flag over time in favor of making this the default behavior).

-- 
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] #9318: "Virtual" behaviour for signal dispatcher and model inheritance

[Django]

#9318: "Virtual" behaviour for signal dispatcher and model inheritance
-+-
 Reporter:  svetlyak40wt |Owner:  jdunck
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  1.0
 Severity:  Normal   |   Resolution:
 Keywords:  model inheritance,   | Triage Stage:  Accepted
  signals, dispatch, proxy,  |  Needs documentation:  0
  subclass   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by carljm):

 Closed #18094 as a duplicate - there's some useful discussion there. Also,
 there's a mailing list thread at https://groups.google.com/d/msg/django-
 developers/2aDFeNAXJgI/-riTuIgNLPQJ

 If a fix is put into place within the signals framework itself, then the
 pre/post_delete signal behavior should be changed so that it does not fire
 separate signals for parent model classes, which it does now (unlike the
 save and init signals).

 I'll also repeat one comment I made on #18094: I think a fix that relies
 on opt-in from the person registering the signal handler is not adequate,
 as this is often not the same person who might be creating a subclass
 (particularly a proxy subclass). A reusable app that registers a signal
 handler for a model ought to be able to assume that that handler will fire
 when instances of that model are involved, without needing to take special
 opt-in steps to ensure that this is still the case when subclasses are
 involved.

-- 
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] #18094: `pre_delete` and `post_delete` signals are not correctly sent in inheritance scenarios involving proxy models

[Django]

#18094: `pre_delete` and `post_delete` signals are not correctly sent in
inheritance scenarios involving proxy models
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:  model proxy multi-   |  Unreviewed
  table inheritance signals delete   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

 * status:  assigned => closed
 * resolution:   => 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] #18094: `pre_delete` and `post_delete` signals are not correctly sent in inheritance scenarios involving proxy models

[Django]

#18094: `pre_delete` and `post_delete` signals are not correctly sent in
inheritance scenarios involving proxy models
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  model proxy multi-   |  Unreviewed
  table inheritance signals delete   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by carljm):

 I started a mailing list thread (https://groups.google.com/d/msg/django-
 developers/2aDFeNAXJgI/-riTuIgNLPQJ) and jdunck pointed out that #9318
 already exists for this, though that ticket is geared towards a fix within
 the signals framework itself. I'm closing this ticket as a duplicate of
 that one, as it's the same problem, regardless of which way we fix it.

-- 
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] r17903 - in django/trunk: django/contrib/gis/geos django/contrib/gis/geos/tests docs/ref/contrib/gis

[noreply]

Author: claudep
Date: 2012-04-12 09:35:28 -0700 (Thu, 12 Apr 2012)
New Revision: 17903

Modified:
   django/trunk/django/contrib/gis/geos/geometry.py
   django/trunk/django/contrib/gis/geos/tests/test_geos.py
   django/trunk/docs/ref/contrib/gis/geos.txt
Log:
Fixed #18039 -- Changed geometry transform without a SRID raise a GEOSException.

This was planned in the official deprecation timeline for 1.5.


Modified: django/trunk/django/contrib/gis/geos/geometry.py
===
--- django/trunk/django/contrib/gis/geos/geometry.py2012-04-11 21:35:08 UTC 
(rev 17902)
+++ django/trunk/django/contrib/gis/geos/geometry.py2012-04-12 16:35:28 UTC 
(rev 17903)
@@ -3,7 +3,6 @@
  inherit from this object.
 """
 # Python, ctypes and types dependencies.
-import warnings
 from ctypes import addressof, byref, c_double
 
 # super-class for mutable list behavior
@@ -507,11 +506,7 @@
 return
 
 if (srid is None) or (srid < 0):
-warnings.warn("Calling transform() with no SRID set does no 
transformation!",
-  stacklevel=2)
-warnings.warn("Calling transform() with no SRID will raise 
GEOSException in v1.5",
-  FutureWarning, stacklevel=2)
-return
+raise GEOSException("Calling transform() with no SRID set is not 
supported")
 
 if not gdal.HAS_GDAL:
 raise GEOSException("GDAL library is not available to transform() 
geometry.")

Modified: django/trunk/django/contrib/gis/geos/tests/test_geos.py
===
--- django/trunk/django/contrib/gis/geos/tests/test_geos.py 2012-04-11 
21:35:08 UTC (rev 17902)
+++ django/trunk/django/contrib/gis/geos/tests/test_geos.py 2012-04-12 
16:35:28 UTC (rev 17903)
@@ -891,64 +891,20 @@
 gdal.HAS_GDAL = old_has_gdal
 
 def test23_transform_nosrid(self):
-""" Testing `transform` method (no SRID) """
-# Raise a warning if SRID <0/None.
-import warnings
-print "\nBEGIN - expecting Warnings; safe to ignore.\n"
+""" Testing `transform` method (no SRID or negative SRID) """
 
-# Test for do-nothing behavior.
-try:
-# Keeping line-noise down by only printing the relevant
-# warnings once.
-warnings.simplefilter('once', UserWarning)
-warnings.simplefilter('once', FutureWarning)
+g = GEOSGeometry('POINT (-104.609 38.255)', srid=None)
+self.assertRaises(GEOSException, g.transform, 2774)
 
-g = GEOSGeometry('POINT (-104.609 38.255)', srid=None)
-g.transform(2774)
-self.assertEqual(g.tuple, (-104.609, 38.255))
-self.assertEqual(g.srid, None)
+g = GEOSGeometry('POINT (-104.609 38.255)', srid=None)
+self.assertRaises(GEOSException, g.transform, 2774, clone=True)
 
-g = GEOSGeometry('POINT (-104.609 38.255)', srid=None)
-g1 = g.transform(2774, clone=True)
-self.assertTrue(g1 is None)
+g = GEOSGeometry('POINT (-104.609 38.255)', srid=-1)
+self.assertRaises(GEOSException, g.transform, 2774)
 
-g = GEOSGeometry('POINT (-104.609 38.255)', srid=-1)
-g.transform(2774)
-self.assertEqual(g.tuple, (-104.609, 38.255))
-self.assertEqual(g.srid, -1)
+g = GEOSGeometry('POINT (-104.609 38.255)', srid=-1)
+self.assertRaises(GEOSException, g.transform, 2774, clone=True)
 
-g = GEOSGeometry('POINT (-104.609 38.255)', srid=-1)
-g1 = g.transform(2774, clone=True)
-self.assertTrue(g1 is None)
-
-finally:
-warnings.simplefilter('default', UserWarning)
-warnings.simplefilter('default', FutureWarning)
-
-print "\nEND - expecting Warnings; safe to ignore.\n"
-
-
-# test warning is raised
-try:
-warnings.simplefilter('error', FutureWarning)
-warnings.simplefilter('ignore', UserWarning)
-
-g = GEOSGeometry('POINT (-104.609 38.255)', srid=None)
-self.assertRaises(FutureWarning, g.transform, 2774)
-
-g = GEOSGeometry('POINT (-104.609 38.255)', srid=None)
-self.assertRaises(FutureWarning, g.transform, 2774, clone=True)
-
-g = GEOSGeometry('POINT (-104.609 38.255)', srid=-1)
-self.assertRaises(FutureWarning, g.transform, 2774)
-
-g = GEOSGeometry('POINT (-104.609 38.255)', srid=-1)
-self.assertRaises(FutureWarning, g.transform, 2774, clone=True)
-finally:
-warnings.simplefilter('default', FutureWarning)
-warnings.simplefilter('default', UserWarning)
-
-
 def test23_transform_nogdal(self):
 """ Testing `transform` method (GDAL not available) """
 old_has_gdal = gdal.HAS_GDAL

Modified: django/trunk/docs/ref/contri

Re: [Django] #18039: transform() should raise a GEOSException when called on a geometry with no SRID value

[Django]

#18039: transform() should raise a GEOSException when called on a geometry with 
no
SRID value
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  GIS   |  Version:  SVN
 Severity:  Release blocker   |   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 claudep):

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


Comment:

 In [17903]:
 {{{
 #!CommitTicketReference repository="" revision="17903"
 Fixed #18039 -- Changed geometry transform without a SRID raise a
 GEOSException.

 This was planned in the official deprecation timeline for 1.5.
 }}}

-- 
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] #18112: contrib.syndication.views: Add hook for getting extra context in feed templates

[Django]

#18112: contrib.syndication.views: Add hook for getting extra context in feed
templates
-+
 Reporter:  slinkp   |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  contrib.syndication  |Version:  SVN
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+
 This seems to me like a useful low-impact hook for authors of Feed
 subclasses...
 I was writing one today and wished I had such a hook.

 It would be intentionally similar to the ``get_context_data`` hook on
 class-based views.

 Usage would look like:

 {{{

 class MyFeed(Feed):
 def get_context_data(**kwargs):
 context = super(MyFeed, self).get_context_data(**kwargs)
 context['foo'] = settings.FOO
 context['more_things'] = app.models.Things.objects.filter(...)
 return context

 }}}

 The description_template and title_template could then make use of the
 extra context variables.

 Attaching a patch; will write tests if this seems worthwhile.

-- 
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] #18094: `pre_delete` and `post_delete` signals are not correctly sent in inheritance scenarios involving proxy models

[Django]

#18094: `pre_delete` and `post_delete` signals are not correctly sent in
inheritance scenarios involving proxy models
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  model proxy multi-   |  Unreviewed
  table inheritance signals delete   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by carljm):

 @charettes - I think your summary of what signals ought to be sent here is
 correct. Re the only/defer issue - if I'm not mistaken, that would be
 fixed by the fix we are discussing here, correct? Given that, I'm not sure
 it deserves it's own ticket, and I don't think we should put in place a
 special-case fix for it.

 @akaariai - Yeah, I think the question of consistency with save signals
 and backwards compatibility is probably worth a thread on -developers -
 I'll try to find time to post about it today.

-- 
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] #17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE

[Django]

#17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE
--+
 Reporter:  slacy |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.4
 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
--+
Changes (by rob@…):

 * cc: rob@… (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.

Re: [Django] #18111: Django autoreload doesn't work for forms.py or tests.py in my app (but does for models.py)

[Django]

#18111: Django autoreload doesn't work for forms.py or tests.py in my app (but 
does
for models.py)
---+--
 Reporter:  stu.axon@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords:  autoreload | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by stu.axon@…):

 Last bit of info for now - here's the (not recommended) __init__.py I came
 up with to reload forms and tests automatically:

 {{{
 try:
 from django.conf import settings
 if settings.DEBUG:
 import forms, tests
 except:
 pass
 }}}

-- 
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] #18111: Django autoreload doesn't work for forms.py or tests.py in my app (but does for models.py)

[Django]

#18111: Django autoreload doesn't work for forms.py or tests.py in my app (but 
does
for models.py)
---+--
 Reporter:  stu.axon@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords:  autoreload | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by stu.axon@…):

 Putting the following code into MY_APP/__init__.py works as a workaround,
 although doesn't seem ideal:


 {{{
 try:
   import forms
 except:
   pass

 }}}

-- 
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] #18111: Django autoreload doesn't work for forms.py or tests.py in my app (but does for models.py)

[Django]

#18111: Django autoreload doesn't work for forms.py or tests.py in my app (but 
does
for models.py)
---+--
 Reporter:  stu.axon@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords:  autoreload | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by stu.axon@…):

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


Comment:

 Note:

 If I open autoreload.py and put the following code

 {{{

 if filename.endswith("models.py"):
 print 'MODEL: ', filename
 elif filename.endswith("forms.py"):
 print 'FORM: ', filename
 }}}


 I can see all my and djangos models, also forms it' uses, but none from my
 app:


 {{{
 MODEL:  /python2.7/site-packages/django/contrib/staticfiles/models.py
 FORM:  /python2.7/site-packages/django/contrib/auth/forms.py
 MODEL:  /python2.7/site-packages/compressor/models.py
 MODEL:  /python2.7/site-packages/django/contrib/messages/models.py
 MODEL:  /python2.7/site-packages/django/contrib/sites/models.py
 MODEL:  ~/projects/jpc/git/MY_SITE/MY_APP/calendar_models.py
 MODEL:  /python2.7/site-packages/django/contrib/formtools/models.py
 MODEL:  /python2.7/site-packages/django/contrib/auth/models.py
 FORM:  /python2.7/site-packages/django/forms/forms.py
 MODEL:  /python2.7/site-packages/django/contrib/admin/models.py
 MODEL:  ~/projects/jpc/git/MY_SITE/MY_APP/models.py
 MODEL:  /python2.7/site-packages/django/contrib/contenttypes/models.py

 MODEL:  /python2.7/site-packages/debug_toolbar/models.py
 MODEL:  /python2.7/site-packages/django/forms/models.py
 MODEL:  /python2.7/site-packages/django/contrib/sessions/models.py
 FORM:  /python2.7/site-packages/django/contrib/admin/forms.py

 }}}

-- 
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] #18111: Django autoreload doesn't work for forms.py or tests.py in my app (but does for models.py)

[Django]

#18111: Django autoreload doesn't work for forms.py or tests.py in my app (but 
does
for models.py)
---+
 Reporter:  stu.axon@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:  autoreload
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I've created a django app that I use within my site.   When I change it's
 models.py reload happens, however for forms.py and tests.py it does not.

-- 
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] #11391: Legacy Database "%" escaping not documented

[Django]

#11391: Legacy Database "%" escaping not documented
-+-
 Reporter:  Greg |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.0
  commands)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  legacy, models.py|  Needs documentation:  0
  inspectdb  |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by anonymous):

 Many people believe that incorporating relaxation therapy into your life
 can be an effective treatment against losing your hair. When your body is
 under stress, blood vessels in the scalp become constricted, which can
 cause your hair to fall out. [http://www.wvweightloss.com/ediets/ediets-
 meal-delivery-save-cash-with-coupons/ ediets meal delivery review]
 Meditation puts you body in a relaxed state, which increases blood flow to
 the scalp.

-- 
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] #10869: ./manage.py makemessages should let users specify input directories

[Django]

#10869: ./manage.py makemessages should let users specify input directories
-+-
 Reporter:  filipnoetzel |Owner:
 Type:  New feature  |   Status:  closed
Component:   |  Version:  1.0
  Internationalization   |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  makemessages i18n|  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jpic):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 Question: what if I want to override a translation from an external app
 for a particular project ? Do I have to fork the 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] #17856: Pass "obj" parameter to get_inline_instances

[Django]

#17856: Pass "obj" parameter to get_inline_instances
---+--
 Reporter:  ybon   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  1.4-beta-1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by aaugustin):

 The idea is accepted, but the current patch lacks tests and docs. You can
 add them and upload a new 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] #18109: Page Stats Middleware break the admin site

[Django]

#18109: Page Stats Middleware break the admin site
---+--
 Reporter:  pcatalina  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Generic views  |  Version:  1.4
 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 aaugustin):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 The wiki is a community resource, and the `StatsMiddleware` is a third
 party add-on, not officially supported by the Django project.

 You should report the problem to the djangomiddlewares project, and maybe
 edit the wiki to mention this problem.

-- 
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] #17856: Pass "obj" parameter to get_inline_instances

[Django]

#17856: Pass "obj" parameter to get_inline_instances
---+--
 Reporter:  ybon   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  1.4-beta-1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by quinode):

 * cc: dguardiola@… (added)


Comment:

 What can be done to see this happen ?

-- 
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] #18110: Improve template cache tag documentation

[Django]

#18110: Improve template cache tag documentation
--+
 Reporter:  julianb   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 For me it was not clear that the fragment name cannot be a variable. I
 just found out by wondering about errors and having a quick look into
 Django's code. It should be made more clear that the second argument will
 not be resolved even though ''all'' the others will be (even the cache
 time gets resolved).

 "It takes at least two arguments: the cache timeout, in seconds, and the
 name to give the cache fragment. For example:"

 should at least be something like

 "It takes at least two arguments: the cache timeout, in seconds, and the
 name to give the cache fragment. The name will be taken as is, do not use
 a variable. For example:"

 https://docs.djangoproject.com/en/dev/topics/cache/#template-fragment-
 caching

-- 
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] #18109: Page Stats Middleware break the admin site

[Django]

#18109: Page Stats Middleware break the admin site
---+
 Reporter:  pcatalina  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Generic views  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The Page Stats Middleware from:
 https://code.djangoproject.com/wiki/PageStatsMiddleware break the admin
 site with the error:


 {{{
 Request Method: GET
 Request URL: http://127.0.0.1:8000/admin/

 Django Version: 1.4
 Python Version: 2.7.2
 Installed Applications:
 ('django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.sites',
  'django.contrib.messages',
  'django.contrib.staticfiles',
  'django.contrib.admin',
  'django.contrib.admindocs')
 Installed Middleware:
 ('django.middleware.common.CommonMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.contrib.messages.middleware.MessageMiddleware',
  'djangomiddlewares.middleware.StatsMiddleware')


 Traceback:
 File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py"
 in get_response
   105. response = middleware_method(request,
 callback, callback_args, callback_kwargs)
 File "/usr/local/src/djangomiddlewares/middleware.py" in process_view
   57. if response and response.content:
 File "/usr/local/lib/python2.7/dist-packages/django/template/response.py"
 in _get_content
   123. raise ContentNotRenderedError('The response content
 must be '

 Exception Type: ContentNotRenderedError at /admin/
 Exception Value: The response content must be rendered before it can be
 accessed.
 }}}


 I make a "temporal" adding:
 {{{
 if request.path.startswith('/admin/'):
 return None
 }}}

 But I think the problem must break other things.

-- 
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.