Re: [Django] #17032: Tests for contrib.auth fail if login signals use templates

[Django]

#17032: Tests for contrib.auth fail if login signals use templates
-+-
 Reporter:  jMyles   |Owner:  jMyles
 Type:  Bug  |   Status:  reopened
Component:  Testing framework|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  contrib.auth, tests  | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * status:  closed => reopened
 * resolution:  wontfix =>
 * stage:  Unreviewed => Design decision needed


Comment:

 The bug described actually exists, and we intend to fix it, even if that
 involves complicated work on test isolation. That's why I'd prefer to keep
 this ticket open (or close it a a duplicate of a more general ticket) at
 this time. I'll mark it as DDN because I can't say exactly how we'll fix
 it.

 Note that the contributing guide states:
 > Please don’t close tickets as “wontfix.” The core developers will make
 the final determination of the fate of a ticket.
 We don't enforce this rule strictly, but in debatable cases, please say
 why you think the proper resolution is "wontfix" and put the ticket in
 DDN.

-- 
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] r17118 - django/trunk/tests/modeltests/timezones

[noreply]

Author: aaugustin
Date: 2011-11-19 23:40:19 -0800 (Sat, 19 Nov 2011)
New Revision: 17118

Modified:
   django/trunk/tests/modeltests/timezones/tests.py
Log:
Disabled tests that require warnings.catch_warnings when running under Python 
2.5.


Modified: django/trunk/tests/modeltests/timezones/tests.py
===
--- django/trunk/tests/modeltests/timezones/tests.py2011-11-19 23:27:20 UTC 
(rev 17117)
+++ django/trunk/tests/modeltests/timezones/tests.py2011-11-20 07:40:19 UTC 
(rev 17118)
@@ -2,6 +2,7 @@
 
 import datetime
 import os
+import sys
 import time
 import warnings
 
@@ -237,6 +238,7 @@
 #@override_settings(USE_TZ=True)
 class NewDatabaseTests(BaseDateTimeTests):
 
+@skipIf(sys.version_info < (2, 6), "this test requires Python >= 2.6")
 def test_naive_datetime(self):
 dt = datetime.datetime(2011, 9, 1, 13, 20, 30)
 with warnings.catch_warnings(record=True) as recorded:
@@ -248,6 +250,7 @@
 # naive datetimes are interpreted in local time
 self.assertEqual(event.dt, dt.replace(tzinfo=EAT))
 
+@skipIf(sys.version_info < (2, 6), "this test requires Python >= 2.6")
 @skipUnlessDBFeature('supports_microsecond_precision')
 def test_naive_datetime_with_microsecond(self):
 dt = datetime.datetime(2011, 9, 1, 13, 20, 30, 405060)
@@ -260,6 +263,7 @@
 # naive datetimes are interpreted in local time
 self.assertEqual(event.dt, dt.replace(tzinfo=EAT))
 
+@skipIf(sys.version_info < (2, 6), "this test requires Python >= 2.6")
 @skipIfDBFeature('supports_microsecond_precision')
 def test_naive_datetime_with_microsecond_unsupported(self):
 dt = datetime.datetime(2011, 9, 1, 13, 20, 30, 405060)

-- 
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] #17265: allow test management command to accept list of tests to exclude

[Django]

#17265: allow test management command to accept list of tests to exclude
---+--
 Reporter:  ptone  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  SVN
 Severity:  Normal |   Resolution:  duplicate
 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 julien):

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


Comment:

 This was actually already reported in #13873. See also #8363.

-- 
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] #17257: Comment that contradicts code in django.contrib.syndication.views

[Django]

#17257: Comment that contradicts code in django.contrib.syndication.views
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.syndication   |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by ptone):

 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


-- 
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] #17262: Refactor the implementations of tzinfo classes

[Django]

#17262: Refactor the implementations of tzinfo classes
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Core (Other) |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  timezone tzinfo  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by ptone):

 * keywords:   => timezone tzinfo
 * stage:  Unreviewed => Accepted


-- 
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] #17264: in_bulk should prep the values with get_prep_value of the model's pk field

[Django]

#17264: in_bulk should prep the values with get_prep_value of the model's pk 
field
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:  needsinfo
 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
-+-
Changes (by ptone):

 * status:  new => closed
 * resolution:   => needsinfo
 * component:  Uncategorized => Database layer (models, ORM)


Comment:

 More info is needed - it is not clear why such behavior would make sense,
 when it should be consistent with any other queryset operations

 It should be the same as qs.filter(pk__in=[...])

-- 
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] #17265: allow test management command to accept list of tests to exclude

[Django]

#17265: allow test management command to accept list of tests to exclude
---+
 Reporter:  ptone  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Testing framework  |Version:  SVN
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Given some of the issues with Django tests no being completely isolated,
 there are times when it would be nice to simple exclude a given set of
 tests for one of the installed apps.

 Something like

 {{{
 ./manage.py test -e app_to_exclude another_to_exclude
 }}}

-- 
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] #10371: Outdated piece in Tutorial pt. 2

[Django]

#10371: Outdated piece in Tutorial pt. 2
---+--
 Reporter:  michaelw   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.0
 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 anonymous):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 This is caused by the browser add-on Binnen-I Be Gone. Since Stacked-
 Inline and Tabular-Inline have "In" in the middle of the word, the add-on
 thinks they're German words that use nonstandard grammar and tries 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.

Re: [Django] #17032: Tests for contrib.auth fail if login signals use templates

[Django]

#17032: Tests for contrib.auth fail if login signals use templates
-+-
 Reporter:  jMyles   |Owner:  jMyles
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.3
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  contrib.auth, tests  | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by anonymous):

 Although the larger issue of conflation of integration and unit testing is
 an important topic of discussion, it seems to me that this patch makes
 good sense no matter what path is chosen.  In fact, it seems to me that
 overriding settings.TEMPLATE_DIRS is simply an oversight; I don't see that
 it reflects any underlying intention to separate unit tests from
 integration tests.

 In any case, this patch will not inhibit a later, more perfect solution,
 and will likely be part of it, no?

 The consequence of failing to accept this patch or one like it is that
 anybody using a template with the login signal is going to have errors in
 the testrunner.  Is that OK?

-- 
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] #10139: Slicing an EmptyQuerySet gives a list, not another EmptyQuerySet

[Django]

#10139: Slicing an EmptyQuerySet gives a list, not another EmptyQuerySet
-+-
 Reporter:  forest   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ori):

 * cc: ori (added)
 * has_patch:  0 => 1
 * ui_ux:   => 0
 * version:  1.0-beta-1 => SVN
 * easy:   => 0


Comment:

 `EmptyQuerySet` is a red herring -- the list is being returned by
 `__getitem__` on the superclass, which is `QuerySet`. The real problem is
 that the documentation for `QuerySet` doesn't currently do a good job
 explaining what type object slicing a QuerySet returns. I've added a patch
 to improve the documentation on this topic.

-- 
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] #12116: needs_context for template filters

[Django]

#12116: needs_context for template filters
-+-
 Reporter:  Suor |Owner:  Suor
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  template filters,| Triage Stage:  Design
  context|  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 Side effects? What about "practicality beats purity"? But since I migrated
 to jinja2 I don't care about this feature anymore, and since nobody cares
 just dropping it seems okay.

 As for the big picture django templates don't feel either practical nor
 convenient, they feel like chains on your arms.
 And custom templatetags make your templates less customizable, inheritable
 and all. Look at django.contrib.admin templates for example.

-- 
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] #17254: ModelBackend should have a get_anonymous_user method

[Django]

#17254: ModelBackend should have a get_anonymous_user method
+--
 Reporter:  riccardodivirgilio  |Owner:  nobody
 Type:  Bug |   Status:  reopened
Component:  contrib.auth|  Version:
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by riccardodivirgilio):

 i've attached a .diff

 the only thing to do then is to change django.contrib.auth.get_user and
 instead of import directly AnonimousUser return the anonymous user class
 defined inside the backend.

 this change have got no compatibility problems for any running django
 application, but can save a lot of problems to django developers in the
 future.

 trust me, because i've got a lot of problems for this small issue. i've to
 write a lot of functions, a lot of getattr, a lot of hasattr, and this is
 not clean and not readable.

-- 
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] #17254: ModelBackend should have a get_anonymous_user method

[Django]

#17254: ModelBackend should have a get_anonymous_user method
+--
 Reporter:  riccardodivirgilio  |Owner:  nobody
 Type:  Bug |   Status:  reopened
Component:  contrib.auth|  Version:
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by riccardodivirgilio):

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


Comment:

 this is what i have done.

 maybe you have missed the point. this is not about my application, or the
 way i found to hack this lack, you asked me for an example.

 the point is that this is not a real backend.

 the current django behavior is to permit a developer to create a custom
 user class, but the middleware do not pass the same class if the user in
 unauthenticated.

 according to me, in a running application, it's a mess to have to
 different kind of classes, depending if the user is authenticated or not.

 i'm not here to ask django to solve my problems, i'm are to solve django
 problems, because my application is alive and running, i'm only
 contributing for an issue, that (according to me) it's big for deploying a
 custom user backend.

 in an object-driving application, i don't see why i have to write function
 and put a lot of time getattr(user, "foo") or hasattr(user, "foo"),
 because it's my app and in my app user has foo attribute, because i have
 decided that is required, so in this login even the Unauthenticated user
 must have a foo attribute.

 django it's a framework, not an application, developers must be able to
 decide which field user class must have, and with the current backend
 developers cannot do that.

 please read the backend.py i have attached, it's better to have an
 attribute in the class and call it using something like
 "self.user_model.objects.get()" for the same reason inside the ModelAdmin
 you call self.model and not directly the model itself.

 whit this simple approach a developer can set a custom user class and a
 permission backend but it's still able to use all views and urls without
 any hack.

 please, read the code, they are just a few line of code that can save a
 lot of problems.

 my question is why do you want to set AnoninmousUser as request.user,
 instead of let developers choose to use django class or a custom class?
 why?

-- 
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] r17117 - in django/trunk: django/db/models/fields docs/topics/i18n tests/modeltests/timezones tests/modeltests/timezones/fixtures

[noreply]

Author: aaugustin
Date: 2011-11-19 15:27:20 -0800 (Sat, 19 Nov 2011)
New Revision: 17117

Added:
   django/trunk/tests/modeltests/timezones/fixtures/tz_users.xml
Removed:
   django/trunk/tests/modeltests/timezones/fixtures/users.xml
Modified:
   django/trunk/django/db/models/fields/__init__.py
   django/trunk/docs/topics/i18n/timezones.txt
   django/trunk/tests/modeltests/timezones/tests.py
Log:
Fixed #17263 -- Added a warning when a naive datetime reaches the database 
layer while time zone support is enabled.

After this commit, timezones.AdminTests will raise warnings because the 
sessions contrib app hasn't been upgraded to support time zones yet.
This will be fixed in an upcoming commit.



Modified: django/trunk/django/db/models/fields/__init__.py
===
--- django/trunk/django/db/models/fields/__init__.py2011-11-19 22:57:47 UTC 
(rev 17116)
+++ django/trunk/django/db/models/fields/__init__.py2011-11-19 23:27:20 UTC 
(rev 17117)
@@ -2,6 +2,7 @@
 import datetime
 import decimal
 import math
+import warnings
 from itertools import tee
 
 from django.db import connection
@@ -789,6 +790,9 @@
 # For backwards compatibility, interpret naive datetimes in local
 # time. This won't work during DST change, but we can't do much
 # about it, so we let the exceptions percolate up the call stack.
+warnings.warn(u"DateTimeField received a naive datetime (%s)"
+  u" while time zone support is active." % value,
+  RuntimeWarning)
 default_timezone = timezone.get_default_timezone()
 value = timezone.make_aware(value, default_timezone)
 return value

Modified: django/trunk/docs/topics/i18n/timezones.txt
===
--- django/trunk/docs/topics/i18n/timezones.txt 2011-11-19 22:57:47 UTC (rev 
17116)
+++ django/trunk/docs/topics/i18n/timezones.txt 2011-11-19 23:27:20 UTC (rev 
17117)
@@ -106,9 +106,9 @@
 
 
 When :setting:`USE_TZ` is ``True``, Django still accepts naive datetime
-objects, in order to preserve backwards-compatibility. It attempts to make them
-aware by interpreting them in the :ref:`default time zone
-`.
+objects, in order to preserve backwards-compatibility. When the database layer
+receives one, it attempts to make it aware by interpreting it in the
+:ref:`default time zone ` and raises a warning.
 
 Unfortunately, during DST transitions, some datetimes don't exist or are
 ambiguous. In such situations, pytz_ raises an exception. Other
@@ -421,11 +421,22 @@
 So the second step is to refactor your code wherever you instanciate datetime
 objects to make them aware. This can be done incrementally.
 :mod:`django.utils.timezone` defines some handy helpers for compatibility
-code: :func:`~django.utils.timezone.is_aware`,
+code: :func:`~django.utils.timezone.now`,
+:func:`~django.utils.timezone.is_aware`,
 :func:`~django.utils.timezone.is_naive`,
 :func:`~django.utils.timezone.make_aware`, and
 :func:`~django.utils.timezone.make_naive`.
 
+Finally, in order to help you locate code that needs upgrading, Django raises
+a warning when you attempt to save a naive datetime to the database. During
+development, you can turn such warnings into exceptions and get a traceback
+by adding to your settings file::
+
+import warnings
+warnings.filterwarnings(
+'error', r"DateTimeField received a naive datetime",
+RuntimeWarning, r'django\.db\.models\.fields')
+
 .. _pytz: http://pytz.sourceforge.net/
 .. _these issues: http://pytz.sourceforge.net/#problems-with-localtime
 .. _tz database: http://en.wikipedia.org/wiki/Tz_database

Copied: django/trunk/tests/modeltests/timezones/fixtures/tz_users.xml (from rev 
17113, django/trunk/tests/modeltests/timezones/fixtures/users.xml)
===
--- django/trunk/tests/modeltests/timezones/fixtures/tz_users.xml   
(rev 0)
+++ django/trunk/tests/modeltests/timezones/fixtures/tz_users.xml   
2011-11-19 23:27:20 UTC (rev 17117)
@@ -0,0 +1,17 @@
+
+
+
+super
+Super
+User
+su...@example.com
+sha1$995a3$6011485ea3834267d719b4c801409b8b1ddd0158
+True
+True
+True
+2001-01-01 
00:00:00+00:00
+2001-01-01 
00:00:00+00:00
+
+
+
+

Deleted: django/trunk/tests/modeltests/timezones/fixtures/users.xml
===
--- django/trunk/tests/modeltests/timezones/fixtures/users.xml  2011-11-19 
22:57:47 UTC (rev 17116)
+++ django/trunk/tests/modeltests/timezones/fixtures/users.xml  2011-11-19 
23:27:20 UTC (rev 17117)
@@ -1,17 +0,0 @@
-
-
-
-super
-Super
-User
-su...@example.com
-

Re: [Django] #17263: When time zone support is active, raise a warning when a naive datetime reaches the database adapter

[Django]

#17263: When time zone support is active, raise a warning when a naive datetime
reaches the database adapter
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Release blocker  |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 In [17117]:
 {{{
 #!CommitTicketReference repository="" revision="17117"
 Fixed #17263 -- Added a warning when a naive datetime reaches the database
 layer while time zone support is enabled.

 After this commit, timezones.AdminTests will raise warnings because the
 sessions contrib app hasn't been upgraded to support time zones yet.
 This will be fixed in an upcoming commit.
 }}}

-- 
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] #17263: When time zone support is active, raise a warning when a naive datetime reaches the database adapter

[Django]

#17263: When time zone support is active, raise a warning when a naive datetime
reaches the database adapter
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Release blocker  |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * has_patch:  0 => 1


Comment:

 Attached patch adds a warning (with docs and 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.

[Changeset] r17116 - in django/branches/releases/1.3.X/docs: intro ref ref/templates topics topics/http

[noreply]

Author: timo
Date: 2011-11-19 14:57:47 -0800 (Sat, 19 Nov 2011)
New Revision: 17116

Modified:
   django/branches/releases/1.3.X/docs/intro/index.txt
   django/branches/releases/1.3.X/docs/ref/django-admin.txt
   django/branches/releases/1.3.X/docs/ref/templates/builtins.txt
   django/branches/releases/1.3.X/docs/topics/http/urls.txt
   django/branches/releases/1.3.X/docs/topics/settings.txt
Log:
[1.3.X] Fixed #17028 - Changed diveintopython.org -> diveintopython.net

Backport of r17115 from trunk.

Modified: django/branches/releases/1.3.X/docs/intro/index.txt
===
--- django/branches/releases/1.3.X/docs/intro/index.txt 2011-11-19 22:57:20 UTC 
(rev 17115)
+++ django/branches/releases/1.3.X/docs/intro/index.txt 2011-11-19 22:57:47 UTC 
(rev 17116)
@@ -31,6 +31,6 @@
 
 .. _python: http://python.org/
 .. _list of Python resources for non-programmers: 
http://wiki.python.org/moin/BeginnersGuide/NonProgrammers
-.. _dive into python: http://diveintopython.org/
+.. _dive into python: http://diveintopython.net/
 .. _dead-tree version: 
http://www.amazon.com/exec/obidos/ASIN/1590593561/ref=nosim/jacobian20
 .. _books about Python: http://wiki.python.org/moin/PythonBooks
\ No newline at end of file

Modified: django/branches/releases/1.3.X/docs/ref/django-admin.txt
===
--- django/branches/releases/1.3.X/docs/ref/django-admin.txt2011-11-19 
22:57:20 UTC (rev 17115)
+++ django/branches/releases/1.3.X/docs/ref/django-admin.txt2011-11-19 
22:57:47 UTC (rev 17116)
@@ -1156,7 +1156,7 @@
 Note that this option is unnecessary in ``manage.py``, because it takes care of
 setting the Python path for you.
 
-.. _import search path: 
http://diveintopython.org/getting_to_know_python/everything_is_an_object.html
+.. _import search path: 
http://diveintopython.net/getting_to_know_python/everything_is_an_object.html
 
 .. django-admin-option:: --settings
 

Modified: django/branches/releases/1.3.X/docs/ref/templates/builtins.txt
===
--- django/branches/releases/1.3.X/docs/ref/templates/builtins.txt  
2011-11-19 22:57:20 UTC (rev 17115)
+++ django/branches/releases/1.3.X/docs/ref/templates/builtins.txt  
2011-11-19 22:57:47 UTC (rev 17116)
@@ -1868,7 +1868,7 @@
 Returns a slice of the list.
 
 Uses the same syntax as Python's list slicing. See
-http://diveintopython.org/native_data_types/lists.html#odbchelper.list.slice
+http://diveintopython.net/native_data_types/lists.html#odbchelper.list.slice
 for an introduction.
 
 Example::

Modified: django/branches/releases/1.3.X/docs/topics/http/urls.txt
===
--- django/branches/releases/1.3.X/docs/topics/http/urls.txt2011-11-19 
22:57:20 UTC (rev 17115)
+++ django/branches/releases/1.3.X/docs/topics/http/urls.txt2011-11-19 
22:57:47 UTC (rev 17116)
@@ -106,7 +106,7 @@
 * ``/articles/2003/03/03/`` would match the final pattern. Django would 
call
   the function ``news.views.article_detail(request, '2003', '03', '03')``.
 
-.. _Dive Into Python's explanation: 
http://diveintopython.org/regular_expressions/street_addresses.html#re.matching.2.3
+.. _Dive Into Python's explanation: 
http://diveintopython.net/regular_expressions/street_addresses.html#re.matching.2.3
 
 Named groups
 

Modified: django/branches/releases/1.3.X/docs/topics/settings.txt
===
--- django/branches/releases/1.3.X/docs/topics/settings.txt 2011-11-19 
22:57:20 UTC (rev 17115)
+++ django/branches/releases/1.3.X/docs/topics/settings.txt 2011-11-19 
22:57:47 UTC (rev 17116)
@@ -39,7 +39,7 @@
 ``mysite.settings``. Note that the settings module should be on the
 Python `import search path`_.
 
-.. _import search path: 
http://diveintopython.org/getting_to_know_python/everything_is_an_object.html
+.. _import search path: 
http://diveintopython.net/getting_to_know_python/everything_is_an_object.html
 
 The django-admin.py utility
 ---

-- 
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] #17028: diveintopython.org links now dead

[Django]

#17028: diveintopython.org links now dead
-+-
 Reporter:  django@… |Owner:  pyriku
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by timo):

 In [17116]:
 {{{
 #!CommitTicketReference repository="" revision="17116"
 [1.3.X] Fixed #17028 - Changed diveintopython.org -> diveintopython.net

 Backport of r17115 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.

Re: [Django] #17028: diveintopython.org links now dead

[Django]

#17028: diveintopython.org links now dead
-+-
 Reporter:  django@… |Owner:  pyriku
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by timo):

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


Comment:

 In [17115]:
 {{{
 #!CommitTicketReference repository="" revision="17115"
 Fixed #17028 - Changed diveintopython.org -> diveintopython.net
 }}}

-- 
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] r17115 - in django/trunk/docs: intro ref ref/templates topics topics/http

[noreply]

Author: timo
Date: 2011-11-19 14:57:20 -0800 (Sat, 19 Nov 2011)
New Revision: 17115

Modified:
   django/trunk/docs/intro/index.txt
   django/trunk/docs/ref/django-admin.txt
   django/trunk/docs/ref/templates/builtins.txt
   django/trunk/docs/topics/http/urls.txt
   django/trunk/docs/topics/settings.txt
Log:
Fixed #17028 - Changed diveintopython.org -> diveintopython.net

Modified: django/trunk/docs/intro/index.txt
===
--- django/trunk/docs/intro/index.txt   2011-11-19 19:56:31 UTC (rev 17114)
+++ django/trunk/docs/intro/index.txt   2011-11-19 22:57:20 UTC (rev 17115)
@@ -31,6 +31,6 @@
 
 .. _python: http://python.org/
 .. _list of Python resources for non-programmers: 
http://wiki.python.org/moin/BeginnersGuide/NonProgrammers
-.. _dive into python: http://diveintopython.org/
+.. _dive into python: http://diveintopython.net/
 .. _dead-tree version: 
http://www.amazon.com/exec/obidos/ASIN/1590593561/ref=nosim/jacobian20
 .. _books about Python: http://wiki.python.org/moin/PythonBooks
\ No newline at end of file

Modified: django/trunk/docs/ref/django-admin.txt
===
--- django/trunk/docs/ref/django-admin.txt  2011-11-19 19:56:31 UTC (rev 
17114)
+++ django/trunk/docs/ref/django-admin.txt  2011-11-19 22:57:20 UTC (rev 
17115)
@@ -1178,7 +1178,7 @@
 Note that this option is unnecessary in ``manage.py``, because it takes care of
 setting the Python path for you.
 
-.. _import search path: 
http://diveintopython.org/getting_to_know_python/everything_is_an_object.html
+.. _import search path: 
http://diveintopython.net/getting_to_know_python/everything_is_an_object.html
 
 .. django-admin-option:: --settings
 

Modified: django/trunk/docs/ref/templates/builtins.txt
===
--- django/trunk/docs/ref/templates/builtins.txt2011-11-19 19:56:31 UTC 
(rev 17114)
+++ django/trunk/docs/ref/templates/builtins.txt2011-11-19 22:57:20 UTC 
(rev 17115)
@@ -1931,7 +1931,7 @@
 Returns a slice of the list.
 
 Uses the same syntax as Python's list slicing. See
-http://diveintopython.org/native_data_types/lists.html#odbchelper.list.slice
+http://diveintopython.net/native_data_types/lists.html#odbchelper.list.slice
 for an introduction.
 
 Example::

Modified: django/trunk/docs/topics/http/urls.txt
===
--- django/trunk/docs/topics/http/urls.txt  2011-11-19 19:56:31 UTC (rev 
17114)
+++ django/trunk/docs/topics/http/urls.txt  2011-11-19 22:57:20 UTC (rev 
17115)
@@ -108,7 +108,7 @@
 * ``/articles/2003/03/03/`` would match the final pattern. Django would call
   the function ``news.views.article_detail(request, '2003', '03', '03')``.
 
-.. _Dive Into Python's explanation: 
http://diveintopython.org/regular_expressions/street_addresses.html#re.matching.2.3
+.. _Dive Into Python's explanation: 
http://diveintopython.net/regular_expressions/street_addresses.html#re.matching.2.3
 
 Named groups
 

Modified: django/trunk/docs/topics/settings.txt
===
--- django/trunk/docs/topics/settings.txt   2011-11-19 19:56:31 UTC (rev 
17114)
+++ django/trunk/docs/topics/settings.txt   2011-11-19 22:57:20 UTC (rev 
17115)
@@ -39,7 +39,7 @@
 ``mysite.settings``. Note that the settings module should be on the
 Python `import search path`_.
 
-.. _import search path: 
http://diveintopython.org/getting_to_know_python/everything_is_an_object.html
+.. _import search path: 
http://diveintopython.net/getting_to_know_python/everything_is_an_object.html
 
 The django-admin.py utility
 ---

-- 
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] #17028: diveintopython.org links now dead

[Django]

#17028: diveintopython.org links now dead
-+-
 Reporter:  django@… |Owner:  pyriku
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by timo):

 Looks like someone has mirrored on diveintopython.net - that seems like a
 good site to use now and if someone wants to get the ball rolling on
 another mirror, no objections from 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.

Re: [Django] #17062: Using postgres, if you rollback the first transaction on a connection, the effect of settings.TIME_ZONE is lost

[Django]

#17062: Using postgres, if you rollback the first transaction on a connection, 
the
effect of settings.TIME_ZONE is lost
-+-
 Reporter:  mwhudson |Owner:  aaugustin
 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):

 The reason of not doing a commit, but instead doing the autocommit -> real
 isolation level dance is saving a db roundtrip. I use my patch attached to
 this ticket (which doesn't apply any more) as an example. The patched one
 shows this in postgresql logs:
 {{{
 26639: LOG:  connection authorized: user=akaj database=testdb1
 26639: LOG:  statement: SHOW default_transaction_isolation
 26639: LOG:  statement: SET default_transaction_isolation TO DEFAULT
 26639: LOG:  statement: SET TIME ZONE 'America/Chicago'
 26639: LOG:  statement: SET default_transaction_isolation TO 'read
 uncommitted'
 26639: LOG:  statement: BEGIN
 26639: LOG:  statement: first real query...
 }}}
 And if you change it so that isolation level is set to real isolation
 level before the set, and commit is done after the SET TIME ZONE, you get
 this:
 {{{
 26731: LOG:  connection authorized: user=akaj database=testdb1
 26731: LOG:  statement: SHOW default_transaction_isolation
 26731: LOG:  statement: SET default_transaction_isolation TO 'read
 uncommitted'
 26731: LOG:  statement: BEGIN
 26731: LOG:  statement: SET TIME ZONE 'America/Chicago'
 26731: LOG:  statement: COMMIT
 26731: LOG:  statement: BEGIN
 26731: LOG:  statement: first real query...
 }}}

 Which is one roundtrip more. Also, BEGIN / COMMIT are probably more
 expensive than the SHOW and SET commands (not tested). This is not really
 important, but on the other hand the cost in code isn't that great,
 either.

 That get_parameter_status idea is a good one. Didn't know it existed. With
 get_parameter_status you can save actually two queries, resetting the
 isolation level, and the setting of time zone. I will create a ticket for
 this... But, if you have correct settings in the postgresql.conf (or for
 the user), get_parameter_status + the isolation level constants reduce the
 connection creation queries to this:
 {{{
 27163: LOG:  connection authorized: user=akaj database=testdb1
 27163: LOG:  statement: SHOW default_transaction_isolation
 27163: LOG:  statement: BEGIN
 27163: LOG:  statement: SELECT "obj_creation
 27163: LOG:  statement: first real query
 }}}
 Not bad :)

-- 
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] #17263: When time zone support is active, raise a warning when a naive datetime reaches the database adapter

[Django]

#17263: When time zone support is active, raise a warning when a naive datetime
reaches the database adapter
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Release blocker  |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Adding this warning shows that Django still uses naive datetimes in many
 places, including the cache framework, the date based generic views, the
 "auth" and "comments" contrib apps.

-- 
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] #12116: needs_context for template filters

[Django]

#12116: needs_context for template filters
-+-
 Reporter:  Suor |Owner:  Suor
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  template filters,| Triage Stage:  Design
  context|  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 Florian Apolloner added on IRC that if we give access to the context, we
 allow users to alter the context in filters, which means the filters can
 have side effects.

-- 
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] #17264: in_bulk should prep the values with get_prep_value of the model's pk field

[Django]

#17264: in_bulk should prep the values with get_prep_value of the model's pk 
field
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:
 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 akaariai):

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


Comment:

 It would make it easier to review this ticket if you provided an example
 of why this is needed.

-- 
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] #17263: When time zone support is active, raise a warning when a naive datetime reaches the database adapter

[Django]

#17263: When time zone support is active, raise a warning when a naive datetime
reaches the database adapter
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Release blocker  |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (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] #6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()

[Django]

#6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()
-+-
 Reporter:  Manfred Wassmann |Owner:  jgelens
   |   Status:  assigned
 Type:  New feature  |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  dceu2011 |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 Assume you have models:
 {{{
 class A1(models.Model):
 foo = models.TextField()

 class B1(models.Model):
 a = models.ForeignKey(A1)
 }}}

 And you do:
 {{{
 qs1 = B1.objects.distinct('a__id', 'a__foo')
 print qs1.query
 qs2 = qs1.distinct('pk')
 print qs2.query
 }}}
 Now you will have a join to A even though you don't have a reference to
 it. The queries generated:

 {{{
 SELECT DISTINCT ON ("obj_creation_speed_a1"."id",
 "obj_creation_speed_a1"."foo") "obj_creation_speed_b1"."id",
 "obj_creation_speed_b1"."a_id" FROM "obj_creation_speed_b1" INNER JOIN
 "obj_creation_speed_a1" ON ("obj_creation_speed_b1"."a_id" =
 "obj_creation_speed_a1"."id")

 SELECT DISTINCT ON ("obj_creation_speed_b1"."id")
 "obj_creation_speed_b1"."id", "obj_creation_speed_b1"."a_id" FROM
 "obj_creation_speed_b1" INNER JOIN "obj_creation_speed_a1" ON
 ("obj_creation_speed_b1"."a_id" = "obj_creation_speed_a1"."id")
 }}}
 Note that in the second query, there is a join into A even if no field of
 A is used in the query. The join should be removed. But I don't think this
 is a blocker issue. If you want to fix this, there are at least these two
 choices:
- Apply the distinct on in the compiler when the query is generated,
 order by is handle this way IIRC.
- Keep record of which aliases are referenced by the DISTINCT ON added
 fields, and subtract the refcount by one for those aliases if the distinct
 on is changed.

 As said before, in my opinion this is not a must-fix in this ticket.

 Now, if you continue from the above created qs1 and issue
 .annotate(Max('a__id')), you will get this query:
 {{{
 qs3 = qs1.annotate(Max('a__id'))
 print qs3.query
 list(qs3)
 }}}

 The query generated is this:
 {{{
 SELECT DISTINCT ON ("obj_creation_speed_a1"."id",
 "obj_creation_speed_a1"."foo") "obj_creation_speed_b1"."id",
 "obj_creation_speed_b1"."a_id", MAX("obj_creation_speed_b1"."a_id") AS
 "a__id__max" FROM "obj_creation_speed_b1" INNER JOIN
 "obj_creation_speed_a1" ON ("obj_creation_speed_b1"."a_id" =
 "obj_creation_speed_a1"."id") GROUP BY "obj_creation_speed_b1"."id",
 "obj_creation_speed_b1"."a_id"
 }}}

 And the list(qs3) will generate this:
 {{{
 django.db.utils.DatabaseError: column "obj_creation_speed_a1.id" must
 appear in the GROUP BY clause or be used in an aggregate function
 LINE 1: SELECT DISTINCT ON ("obj_creation_speed_a1"."id", "obj_creat...
 ^
 }}}

 You could "fix" this by appending the DISTINCT ON columns into the group
 by clause. Unfortunately (without going into details) the results aren't
 what the user would expect. If you want the results the user expects, you
 would need to do a subquery. If the distinct on is in the inner query or
 group by is in the inner query depends on the order in which the .annotate
 and .distinct are applied. A good fix for this would be to raise
 NotImplementedError("Can't handle queries with aggregates and distinct on
 clause"). I have written some SQL by hand, and can't remember ever using
 distinct on and group by in the same query. Maybe there is some use case,
 but I just don't see the need to block on this issue, either.

-- 
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] #17264: in_bulk should prep the values with get_prep_value of the model's pk field

[Django]

#17264: in_bulk should prep the values with get_prep_value of the model's pk 
field
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 currently in_bulk just does filter(pk__in=id_list), but id_list should
 have its values cleaned with the model's pk field's get_prep_value
 function before filtering.

-- 
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] #6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()

[Django]

#6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()
-+-
 Reporter:  Manfred Wassmann |Owner:  jgelens
   |   Status:  assigned
 Type:  New feature  |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  dceu2011 |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by jgelens):

 @akaariai
 * Added a docstring to add_distinct_fields.
 * If you specify distinct(field_list) multiple times it will overwrite the
 previous one. This is the intended behavior.
 * The fields in DISTINCT ON are always in the select list. I guess your
 explanation can't happen. If it does could you explain further and give
 some examples?
 * I discussed the true_or_false argument removal with Russell and Alex
 during the DjangoCon in Amsterdam this year. As it's a undocumented
 feature and we couldn't find any usage of it on the web, we decided to
 remove the argument. It's a weird argument anyway ;) .

-- 
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] #17263: When time zone support is active, raise a warning when a naive datetime reaches the database adapter

[Django]

#17263: When time zone support is active, raise a warning when a naive datetime
reaches the database adapter
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Release blocker  |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by lukeplant):

 * severity:  Normal => Release blocker
 * stage:  Design decision needed => Accepted


Comment:

 Agreed, and in fact I think we should ensure this gets in for 1.4, so that
 we can mention it in the upgrading notes, therefore making it a release
 blocker.

-- 
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] #15888: Inspect `settings.CACHES` in order to make`createcachetable` automatic

[Django]

#15888: Inspect `settings.CACHES` in order to make`createcachetable` automatic
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Cache system)   |  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
--+
Changes (by aaugustin):

 * owner:  aaugustin => nobody


-- 
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] #15255: DB Cache table creation (createcachetable) ignores the DB Router

[Django]

#15255: DB Cache table creation (createcachetable) ignores the DB Router
-+-
 Reporter:  zvikico  |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Core (Cache system)  |  Version:  1.3-beta
 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 aaugustin):

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


Comment:

 In [17114]:
 {{{
 #!CommitTicketReference repository="" revision="17114"
 Fixed #15255 -- Ensured createcachetable honors database routers.
 }}}

-- 
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] r17114 - in django/trunk: django/contrib/gis/db/backends/spatialite django/core/management/commands django/db/backends tests/regressiontests/cache

[noreply]

Author: aaugustin
Date: 2011-11-19 11:56:31 -0800 (Sat, 19 Nov 2011)
New Revision: 17114

Modified:
   django/trunk/django/contrib/gis/db/backends/spatialite/creation.py
   django/trunk/django/core/management/commands/createcachetable.py
   django/trunk/django/db/backends/creation.py
   django/trunk/tests/regressiontests/cache/tests.py
Log:
Fixed #15255 -- Ensured createcachetable honors database routers.


Modified: django/trunk/django/contrib/gis/db/backends/spatialite/creation.py
===
--- django/trunk/django/contrib/gis/db/backends/spatialite/creation.py  
2011-11-19 15:08:07 UTC (rev 17113)
+++ django/trunk/django/contrib/gis/db/backends/spatialite/creation.py  
2011-11-19 19:56:31 UTC (rev 17114)
@@ -61,9 +61,7 @@
 for cache_alias in settings.CACHES:
 cache = get_cache(cache_alias)
 if isinstance(cache, BaseDatabaseCache):
-from django.db import router
-if router.allow_syncdb(self.connection.alias, 
cache.cache_model_class):
-call_command('createcachetable', cache._table, 
database=self.connection.alias)
+call_command('createcachetable', cache._table, 
database=self.connection.alias)
 
 # Get a cursor (even though we don't need one yet). This has
 # the side effect of initializing the test database.

Modified: django/trunk/django/core/management/commands/createcachetable.py
===
--- django/trunk/django/core/management/commands/createcachetable.py
2011-11-19 15:08:07 UTC (rev 17113)
+++ django/trunk/django/core/management/commands/createcachetable.py
2011-11-19 19:56:31 UTC (rev 17114)
@@ -1,7 +1,8 @@
 from optparse import make_option
 
+from django.core.cache.backends.db import BaseDatabaseCache
 from django.core.management.base import LabelCommand
-from django.db import connections, transaction, models, DEFAULT_DB_ALIAS
+from django.db import connections, router, transaction, models, 
DEFAULT_DB_ALIAS
 
 class Command(LabelCommand):
 help = "Creates the table needed to use the SQL cache backend."
@@ -18,8 +19,11 @@
 requires_model_validation = False
 
 def handle_label(self, tablename, **options):
-alias = options.get('database')
-connection = connections[alias]
+db = options.get('database', DEFAULT_DB_ALIAS)
+cache = BaseDatabaseCache(tablename, {})
+if not router.allow_syncdb(db, cache.cache_model_class):
+return
+connection = connections[db]
 fields = (
 # "key" is a reserved word in MySQL, so use "cache_key" instead.
 models.CharField(name='cache_key', max_length=255, unique=True, 
primary_key=True),
@@ -50,4 +54,4 @@
 curs.execute("\n".join(full_statement))
 for statement in index_output:
 curs.execute(statement)
-transaction.commit_unless_managed(using=alias)
+transaction.commit_unless_managed(using=db)

Modified: django/trunk/django/db/backends/creation.py
===
--- django/trunk/django/db/backends/creation.py 2011-11-19 15:08:07 UTC (rev 
17113)
+++ django/trunk/django/db/backends/creation.py 2011-11-19 19:56:31 UTC (rev 
17114)
@@ -255,9 +255,7 @@
 for cache_alias in settings.CACHES:
 cache = get_cache(cache_alias)
 if isinstance(cache, BaseDatabaseCache):
-from django.db import router
-if router.allow_syncdb(self.connection.alias, 
cache.cache_model_class):
-call_command('createcachetable', cache._table, 
database=self.connection.alias)
+call_command('createcachetable', cache._table, 
database=self.connection.alias)
 
 # Get a cursor (even though we don't need one yet). This has
 # the side effect of initializing the test database.

Modified: django/trunk/tests/regressiontests/cache/tests.py
===
--- django/trunk/tests/regressiontests/cache/tests.py   2011-11-19 15:08:07 UTC 
(rev 17113)
+++ django/trunk/tests/regressiontests/cache/tests.py   2011-11-19 19:56:31 UTC 
(rev 17114)
@@ -16,6 +16,7 @@
 from django.core.cache import get_cache, DEFAULT_CACHE_ALIAS
 from django.core.cache.backends.base import (CacheKeyWarning,
 InvalidCacheBackendError)
+from django.db import router
 from django.http import HttpResponse, HttpRequest, QueryDict
 from django.middleware.cache import (FetchFromCacheMiddleware,
 UpdateCacheMiddleware, CacheMiddleware)
@@ -775,6 +776,44 @@
 self.perform_cull_test(50, 18)
 
 
+class DBCacheRouter(object):
+"""A router that puts the cache table on the 'other' database."""
+
+def db_for_read(self, model, **hints):
+if model._meta.app_label == 'django_cache':
+return 'other'
+
+def db_for_write(self, 

Re: [Django] #17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled

[Django]

#17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Here are the comments that were sent to the mailing list:

 ''Aymeric Augustin (myself)''

 Under PostgreSQL, provided the current time zone has a valid name (e.g.
 it's provided by pytz), we could temporarily set the connection's timezone
 to this time zone and restore it to UTC afterwards. With other backends, I
 can't think of a simpler solution than fetching all values and doing the
 aggregation in Python. Neither of these  thrills me, so for the time
 being, I've documented this as a known limitation.

 ''Luke Plant''

 You could argue a case for saying that the behaviour has some advantages:
 if one admin user filters a list of objects by date, and sends the link to
 a colleague, they would probably expect the colleague to end up with the
 same list of objects. But even if that isn't very convincing, I'm happy
 with this limitation given the implementation difficulties of fixing it.

 ''Anssi Kääriäinen''

 I don't see this as a major issue, except if Django needs to support this
 behaviour for backwards compatibility reasons. But as this is documented
 as a limitation, not as a "feature",  this is fine as is. It would be nice
 to fix this in the future. For PostgreSQL, tracking the current time zone
 for the connection seems a bit hard - we can't rely a SET TIME ZONE is
 really going to be in effect, unless we also track rollbacks/commits (see
 #17062). And changing it for every DB query seems bad, too. One idea is to
 use "SELECT col AT TIME ZONE 'GMT+2' as col". This way the session time
 zone doesn't need to be changed. For example:
 {{{
 > SET TIME ZONE 'UTC';
 > create table testt(dt timestamptz);
 > insert into testt values(now());
 > select dt at time zone 'GMT+2' as dt from testt;
  2011-11-18 07:06:47.834771
 > select dt at time zone 'Europe/Helsinki' as dt from testt;
  2011-11-18 11:06:47.834771
 }}}
 Oracle seems to have
 [http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm a
 similar feature]. I don't know if other databases offer similar
 functionality. MySQL has probably support for something similar when using
 TIMESTAMP columns. But as said, I don't see this as a major issue. It
 would be nice to support this some day.

-- 
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] #17053: Add a note about USE_THOUSAND_SEPARATOR in localization docs

[Django]

#17053: Add a note about USE_THOUSAND_SEPARATOR in localization docs
--+
 Reporter:  shelldweller  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.3
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by krzysiumed):

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


Comment:

 I've closed this ticket because there is proper annotation on
 [https://docs.djangoproject.com/en/1.3/topics/i18n/localization/#creating-
 custom-format-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.

[Django] #17263: When time zone support is active, raise a warning when a naive datetime reaches the database adapter

[Django]

#17263: When time zone support is active, raise a warning when a naive datetime
reaches the database adapter
-+-
   Reporter:  aaugustin  |  Owner:  aaugustin
   Type: | Status:  new
  Cleanup/optimization   |Version:
  Component:  Database   |   Keywords:
  layer (models, ORM)|  Has patch:  0
   Severity:  Normal |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 I haven't done it because I thought it would be too obnoxious -- for
 instance, if you're using a third-party app that uses datetimes in a non-
 trivial way and hasn't been upgraded yet.

 But a good argument in favor of such a warning was made
 [http://groups.google.com/group/django-developers/msg/682a41fd2c8da431 on
 the mailing list], and it's easy to filter the warning out with one line
 in your settings file if you don't care.

-- 
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] #14253: TIME_ZONE not respected by Today and Now widgets in admin

[Django]

#14253: TIME_ZONE not respected by Today and Now widgets in admin
-+-
 Reporter:  adamnelson   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  1.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Fixed on
Has patch:  0|  a branch
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  1
-+-
Changes (by aaugustin):

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


Comment:

 I think we can consider this fixed at r17106, which addressed #2626.

-- 
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] #12116: needs_context for template filters

[Django]

#12116: needs_context for template filters
-+-
 Reporter:  Suor |Owner:  Suor
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  template filters,| Triage Stage:  Design
  context|  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 I still think filters with arguments or templatetags are the way to go for
 your examples.

 Django [https://docs.djangoproject.com/en/dev/faq/general/#django-appears-
 to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-
 the-template-how-come-you-don-t-use-the-standard-names isn't strongly
 committed to a MVC model], and in the end, "practicality beats purity".

-- 
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] #17262: Refactor the implementations of tzinfo classes

[Django]

#17262: Refactor the implementations of tzinfo classes
-+-
   Reporter:  aaugustin  |  Owner:  aaugustin
   Type: | Status:  new
  Cleanup/optimization   |Version:
  Component:  Core   |   Keywords:
  (Other)|  Has patch:  0
   Severity:  Normal |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 Since the merge of the time zone support branch, `django.utils.tzinfo` and
 `django.utils.timezone` provide subtly different implementations of a
 tzinfo subclass representing local time.

 The reason is explained at the bottom of [http://groups.google.com/group
 /django-developers/msg/c05b469e4335c6cc this message]. In short, the
 former is used for display and focuses on robustness; the latter is used
 for time zone support and focuses on correctness.

 I think `django.utils.tzinfo` should be refactored and merged into
 `django.utils.timezone`, but that's probably not doable in a totally
 backwards-compatible fashion.

-- 
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] #17166: The fixture documentation tells nowhere that you can (should?) use FIXTURE_DIRS in your settings.py

[Django]

#17166: The fixture documentation tells nowhere that you can (should?) use
FIXTURE_DIRS in your settings.py
--+
 Reporter:  anonymous |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by krzysiumed):

 * cc: krzysiumed@… (added)


Comment:

 I've sent another version, in my opinion slightly better.

-- 
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] #17261: Refactor parsing of date and times

[Django]

#17261: Refactor parsing of date and times
-+-
   Reporter:  aaugustin  |  Owner:  aaugustin
   Type: | Status:  new
  Cleanup/optimization   |Version:  SVN
  Component: |   Keywords:
  Uncategorized  |  Has patch:  0
   Severity:  Normal |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 Since the merge of the time zone support branch, `django.utils.dateparse`
 provides parsing functions for dates and times.

 Other parts of Django may take advantage of this module to parse
 structured dates and times (ISO format or similar).

-- 
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] #17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled

[Django]

#17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  SVN
  layer (models, ORM)|   Keywords:
   Severity:  Normal |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 Aggregation on dates is performed in UTC (the database timezone) when
 `settings.USE_TZ = True`, while an end user may expect its current time
 zone to be taken into account. This is a known problem in the initial
 implementation of time zone support.

 It affects:
 - `QuerySet.dates()`,
 -  the `year`, `month`, `day`, and `week_day` lookups,
 - `date_hierarchy` in the admin,
 - the date based generic views.

-- 
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] #17062: Using postgres, if you rollback the first transaction on a connection, the effect of settings.TIME_ZONE is lost

[Django]

#17062: Using postgres, if you rollback the first transaction on a connection, 
the
effect of settings.TIME_ZONE is lost
-+-
 Reporter:  mwhudson |Owner:  aaugustin
 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 aaugustin):

 akaariai, is there a reason why your patch changes the isolation level
 rather than just calling `transaction.commit()` after the `SET TIME ZONE`
 query?

 FYI, I just committed a patch to use the constants for isolation levels
 (r17112).

 Optimizing the case when `settings.TIME_ZONE` is PostgreSQL's default time
 zone could save 1 query per request (if I understand correctly). I suppose
 we'd check the server timezone with
 
[http://initd.org/psycopg/docs/connection.html?highlight=timezone#connection.get_parameter_status
 get_parameter_status]. Would you mind opening a separate ticket for this?

-- 
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] #2879: Add live test server support to test framework

[Django]

#2879: Add live test server support to test framework
-+-
 Reporter:  Mikeal Rogers|Owner:  devin
   |   Status:  new
 Type:  New feature  |  Version:
Component:  Testing framework|   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 tomchristie):

 It looks like there's a race condition involved in reloading the database
 inside the `LiveServerThread`.

 It's sporadic, but if you run an empty `LiveServerTestCase` test a few
 times you should see it manifest.
 The process will fail to shutdown after the test completes.

 {{{
 class LiveServerTest(LiveServerTestCase):
 def test_live_server(self):
 pass
 }}}


 It looks like this was previously being masked because the Selenium tests
 were preventing the race from occuring.

 I've narrowed things down to the Database creation in
 `LiveServerThread.run`.
 If that's commented out, or if it's moved into the `__init__` (ie out of
 the new thread), the process shuts down fine.

 I was thinking that it looked like the connection just needed to be
 explicitly closed and/or rolled back at the end of `run()`,
 but that didn't solve things - just made the race much less likely to
 occur, but still present occasionally.

 I'm not exactly sure what's needed to fix it, so would appreciate some
 other eyes. :)

 I'll try to find the time in the next couple of days to write up a few
 tests for !LiveServerTestCase, that
 use urllib2 or httplib to check the basics:

 * Serving views.
 * Serving 404s.
 * Serving static media.
 * Serving uploaded media, if MEDIA_URL is set.  (I'm not sure this is done
 right now? It should be, right?)
 * Ensure that fixtures are properly loaded in the live server thread.
 * Ensure that model instances are properly created in the live server
 thread.
 * Ensure that there's proper database seperation between test 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] #17254: ModelBackend should have a get_anonymous_user method

[Django]

#17254: ModelBackend should have a get_anonymous_user method
+--
 Reporter:  riccardodivirgilio  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.auth|  Version:
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by ptone):

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


Comment:

 This is basically a dupe of #3011

 see also: http://stackoverflow.com/questions/896421/how-to-change-default-
 django-user-model-to-fit-my-needs

 AnonUsers and AuthUsers are fundamentally different in having a DB
 instance.

 You may find it easier to write a util method that takes a user
 user_has_discount(request.user) then factor all your checking into that

-- 
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] #17254: ModelBackend should have a get_anonymous_user method

[Django]

#17254: ModelBackend should have a get_anonymous_user method
+--
 Reporter:  riccardodivirgilio  |Owner:  nobody
 Type:  Bug |   Status:  reopened
Component:  contrib.auth|  Version:
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by ptone):

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


Comment:

 reopening to change resolution

-- 
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] #17259: error in http post data parser

[Django]

#17259: error in http post data parser
---+--
 Reporter:  bayazee@…  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:
 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
---+--

Old description:

> Traceback (most recent call last):
>
>   File "/usr/local/lib/python2.6/site-
> packages/django/core/handlers/base.py", line 95, in get_response
> response = middleware_method(request, callback, callback_args,
> callback_kwargs)
>
>   File "/usr/local/lib/python2.6/site-
> packages/django/middleware/csrf.py", line 164, in process_view
> request_csrf_token = request.POST.get('csrfmiddlewaretoken', "")
>
>   File "/usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py", line 171, in _get_post
> self._load_post_and_files()
>
>   File "/usr/local/lib/python2.6/site-
> packages/django/core/handlers/wsgi.py", line 137, in _load_post_and_files
> self._post, self._files = self.parse_file_upload(self.META,
> self.environ['wsgi.input'])
>
>   File "/usr/local/lib/python2.6/site-packages/django/http/__init__.py",
> line 123, in parse_file_upload
> parser = MultiPartParser(META, post_data, self.upload_handlers,
> self.encoding)
>
>   File "/usr/local/lib/python2.6/site-
> packages/django/http/multipartparser.py", line 80, in __init__
> raise MultiPartParserError("Invalid content length: %r" %
> content_length)
>
> MultiPartParserError: Invalid content length: 0

New description:

 {{{
 Traceback (most recent call last):

   File "/usr/local/lib/python2.6/site-
 packages/django/core/handlers/base.py", line 95, in get_response
 response = middleware_method(request, callback, callback_args,
 callback_kwargs)

   File "/usr/local/lib/python2.6/site-packages/django/middleware/csrf.py",
 line 164, in process_view
 request_csrf_token = request.POST.get('csrfmiddlewaretoken', "")

   File "/usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py", line 171, in _get_post
 self._load_post_and_files()

   File "/usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py", line 137, in _load_post_and_files
 self._post, self._files = self.parse_file_upload(self.META,
 self.environ['wsgi.input'])

   File "/usr/local/lib/python2.6/site-packages/django/http/__init__.py",
 line 123, in parse_file_upload
 parser = MultiPartParser(META, post_data, self.upload_handlers,
 self.encoding)

   File "/usr/local/lib/python2.6/site-
 packages/django/http/multipartparser.py", line 80, in __init__
 raise MultiPartParserError("Invalid content length: %r" %
 content_length)

 MultiPartParserError: Invalid content length: 0
 }}}

--

Comment (by kmtracey):

 Also if you search trac
 
(https://code.djangoproject.com/search?q=MultiPartParserError+%22Invalid+content+length%22=1=on)
 you will find at least one similar report that may help you in isolating
 the cause of this problem. When it has been reported before the cause was
 found to be outside of Django itself.

-- 
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] #15646: Document that the FileField's path can not be relied on until the model is saved

[Django]

#15646: Document that the FileField's path can not be relied on until the model 
is
saved
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  storage system path  | Triage Stage:  Accepted
  upload_to  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by kmtracey):

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


Comment:

 In [17113]:
 {{{
 #!CommitTicketReference repository="" revision="17113"
 Fix #15646: Document that a FileField's full path can't be relied upon
 until its model has been saved to the database. Thanks poirier.
 }}}

-- 
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] r17113 - in django/trunk/docs: ref/models topics

[noreply]

Author: kmtracey
Date: 2011-11-19 07:08:07 -0800 (Sat, 19 Nov 2011)
New Revision: 17113

Modified:
   django/trunk/docs/ref/models/fields.txt
   django/trunk/docs/topics/files.txt
Log:
Fix #15646: Document that a FileField's full path can't be relied upon until 
its model has been saved to the database. Thanks poirier.


Modified: django/trunk/docs/ref/models/fields.txt
===
--- django/trunk/docs/ref/models/fields.txt 2011-11-19 14:18:44 UTC (rev 
17112)
+++ django/trunk/docs/ref/models/fields.txt 2011-11-19 15:08:07 UTC (rev 
17113)
@@ -572,6 +572,11 @@
 :class:`~django.core.files.File` class reference and the :doc:`/topics/files`
 topic guide.
 
+.. note::
+The file is saved as part of saving the model in the database, so the 
actual
+file name used on disk cannot be relied on until after the model has been
+saved.
+
 The uploaded file's relative URL can be obtained using the
 :attr:`~django.db.models.fields.FileField.url` attribute. Internally,
 this calls the :meth:`~django.core.files.storage.Storage.url` method of the

Modified: django/trunk/docs/topics/files.txt
===
--- django/trunk/docs/topics/files.txt  2011-11-19 14:18:44 UTC (rev 17112)
+++ django/trunk/docs/topics/files.txt  2011-11-19 15:08:07 UTC (rev 17113)
@@ -45,6 +45,12 @@
 This object -- ``car.photo`` in the example -- is a ``File`` object, which 
means
 it has all the methods and attributes described below.
 
+.. note::
+The file is saved as part of saving the model in the database, so the 
actual
+file name used on disk cannot be relied on until after the model has been
+saved.
+
+
 The ``File`` object
 ===
 

-- 
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] #2879: Add live test server support to test framework

[Django]

#2879: Add live test server support to test framework
-+-
 Reporter:  Mikeal Rogers|Owner:  devin
   |   Status:  new
 Type:  New feature  |  Version:
Component:  Testing framework|   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 jezdez):

 Interesting patch indeed, I have a few issue I'd like to see fixed first
 though:

 - In `AdminSeleniumWebDriverTestCase` (shorter name?) the `setUp` method
 re-imports and instantiates the webdriver for every test method. Using the
 setUpClass class method would be preferred (unless I'm missing some need
 for resetting it all the time).

 - The new `LIVE_TEST_SERVER_HOST` and `LIVE_TEST_SERVER_PORT` settings are
 much too specific for Selenium (including the fact that "http" is
 hardcoded in `LiveServerTestCase`). I suggest introducing justa
 `LIVE_TEST_SERVER` setting instead and ask the users to give it a full
 URL, e.g. 'http://localhost/8081/'). Even though we have separate settings
 for email servers (`EMAIL_HOST` and `EMAIL_PORT`) the live test server has
 a lax API and shouldn't be hardwired to require protocol, host and port.

 - The docs don't mention how to run the Selenium based tests except
 installing the selenium Python library. I suggest to add a small section
 about how to get Selenium to run in the first place (basically only where
 to download and how to run, like mentioned on
 http://pypi.python.org/pypi/selenium).

 Other than that this looks good 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] r17112 - django/trunk/django/db/backends/postgresql_psycopg2

[noreply]

Author: aaugustin
Date: 2011-11-19 06:18:44 -0800 (Sat, 19 Nov 2011)
New Revision: 17112

Modified:
   django/trunk/django/db/backends/postgresql_psycopg2/base.py
   django/trunk/django/db/backends/postgresql_psycopg2/creation.py
Log:
Used symbolic constants for psycopg2 isolation levels.

Django used the value 1 = ISOLATION_LEVEL_READ_UNCOMMITTED in some places, but
PostgreSQL doesn't provide "read uncommited", it uses "read committed" instead:
http://www.postgresql.org/docs/9.1/static/transaction-iso.html. For clarity,
this commit uses ISOLATION_LEVEL_READ_COMMITTED = 2 where 1 was previously used.



Modified: django/trunk/django/db/backends/postgresql_psycopg2/base.py
===
--- django/trunk/django/db/backends/postgresql_psycopg2/base.py 2011-11-19 
11:38:40 UTC (rev 17111)
+++ django/trunk/django/db/backends/postgresql_psycopg2/base.py 2011-11-19 
14:18:44 UTC (rev 17112)
@@ -108,7 +108,11 @@
 self.features = DatabaseFeatures(self)
 autocommit = self.settings_dict["OPTIONS"].get('autocommit', False)
 self.features.uses_autocommit = autocommit
-self._set_isolation_level(int(not autocommit))
+if autocommit:
+level = psycopg2.extensions.ISOLATION_LEVEL_AUTOCOMMIT
+else:
+level = psycopg2.extensions.ISOLATION_LEVEL_READ_COMMITTED
+self._set_isolation_level(level)
 self.ops = DatabaseOperations(self)
 self.client = DatabaseClient(self)
 self.creation = DatabaseCreation(self)
@@ -189,7 +193,7 @@
 the same transaction is visible across all the queries.
 """
 if self.features.uses_autocommit and managed and not 
self.isolation_level:
-self._set_isolation_level(1)
+
self._set_isolation_level(psycopg2.extensions.ISOLATION_LEVEL_READ_COMMITTED)
 
 def _leave_transaction_management(self, managed):
 """
@@ -197,7 +201,7 @@
 leaving transaction management.
 """
 if self.features.uses_autocommit and not managed and 
self.isolation_level:
-self._set_isolation_level(0)
+
self._set_isolation_level(psycopg2.extensions.ISOLATION_LEVEL_AUTOCOMMIT)
 
 def _set_isolation_level(self, level):
 """
@@ -205,7 +209,7 @@
 levels. This doesn't touch the uses_autocommit feature, since that
 controls the movement *between* isolation levels.
 """
-assert level in (0, 1)
+assert level in range(5)
 try:
 if self.connection is not None:
 self.connection.set_isolation_level(level)

Modified: django/trunk/django/db/backends/postgresql_psycopg2/creation.py
===
--- django/trunk/django/db/backends/postgresql_psycopg2/creation.py 
2011-11-19 11:38:40 UTC (rev 17111)
+++ django/trunk/django/db/backends/postgresql_psycopg2/creation.py 
2011-11-19 14:18:44 UTC (rev 17112)
@@ -1,3 +1,5 @@
+import psycopg2.extensions
+
 from django.db.backends.creation import BaseDatabaseCreation
 from django.db.backends.util import truncate_name
 
@@ -81,4 +83,5 @@
 def _prepare_for_test_db_ddl(self):
 """Rollback and close the active transaction."""
 self.connection.connection.rollback()
-self.connection.connection.set_isolation_level(0)
+self.connection.connection.set_isolation_level(
+psycopg2.extensions.ISOLATION_LEVEL_AUTOCOMMIT)

-- 
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] #2879: Add live test server support to test framework

[Django]

#2879: Add live test server support to test framework
-+-
 Reporter:  Mikeal Rogers|Owner:  devin
   |   Status:  new
 Type:  New feature  |  Version:
Component:  Testing framework|   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 adamnelson):

 I don't know how big of a shift it would be but I've used
 [http://splinter.cobrateam.info/ Splinter] for testing in order to get
 around Selenium deficiencies and it works on Python 2.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.

Re: [Django] #17254: ModelBackend should have a get_anonymous_user method

[Django]

#17254: ModelBackend should have a get_anonymous_user method
+--
 Reporter:  riccardodivirgilio  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.auth|  Version:
 Severity:  Normal  |   Resolution:  needsinfo
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by anonymous):

 * 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] #17254: ModelBackend should have a get_anonymous_user method

[Django]

#17254: ModelBackend should have a get_anonymous_user method
+--
 Reporter:  riccardodivirgilio  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.auth|  Version:
 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):

 with this implementation of backend i can do something like this
 do not use "django.contrib.auth" in the INSTALLED_APP, but use
 "myapp.auth" to define User class and Permission class (with duck type mot
 hod of django class) and still use django.contrib.auth.urls and
 django.contrib.middleware.AuthenticationMiddleware, and everything works
 (with a different user and permission db_table)

-- 
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] #17254: ModelBackend should have a get_anonymous_user method

[Django]

#17254: ModelBackend should have a get_anonymous_user method
+--
 Reporter:  riccardodivirgilio  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.auth|  Version:
 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 riccardodivirgilio):

 sorry for my english, i'm italian and i just woke up... yesterday i was
 drunk so sorry

 but read the backends.py for me it's much more customizable in the way i
 wrote...
 the methods inside the backend use self.user_class.objects.get to get an
 user, instead of doing User.objects.get
 i added a get_anonymous_user to get a fresh instance of AnonymousUser,
 this method must be used by the middleware
 for me doing an import such "from django.contrib.auth.models import
 AnonymousUser" and then call directly AnonymousUser(), it'wrong, because
 if you do something like this, i have to rewrite more code to make
 login/logout and middleware work the way i need.

 the way i wrote the backend, to subclass it you simply need to hook your
 user model and your anonimoususer class, and django will do the dirty of
 work of login, logout, password change and so on.

 bye bye, my django friends!

-- 
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] #17254: ModelBackend should have a get_anonymous_user method

[Django]

#17254: ModelBackend should have a get_anonymous_user method
+--
 Reporter:  riccardodivirgilio  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.auth|  Version:
 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):

 when you subclass the user, i would like to subclass even the
 AnonymousUser in request to check the user attributes without using
 getattr, or define custom methods, even for an AnonymousUser user.

 for example, i have got a field that is called "user_discount" and i have
 got a method that return the final price of the user.

 i use this method a lot of time in the site, because it's an commerce, and
 it's useful to do request.user.dicounted_price("120") without doing a mess
 like this get_discounted_price_from_user(user, 120), and using a function
 and not a class, and in every part of my code i have to check if user
 is_authenticated before using custom method of my user class.

 for me an AnonymousUser, should be a subclass of the user class, but it
 must be declared importing the user class from the backend and then
 subclassing it.

 i've a attached a new backend file,

 this is an easy way to allow developers to completely use another User and
 Permission backend using 3 line of code (read the backends.py i've
 attached)

 class MyModelBackend(ModelBackend):

 user_class = MyUser
 permission_class = MyPermission
 anonymoususer_class = MyAnonymousUser

 with this class i can set my own model table for existing legacy user and
 permission, without rewrite login, logout, password_change and so on...

-- 
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] #17259: error in http post data parser

[Django]

#17259: error in http post data parser
---+--
 Reporter:  bayazee@…  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:
 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
---+--
Changes (by russellm):

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


Comment:

 A stack trace isn't a bug report.

 If you care to provide instructions detailing how you generated this stack
 trace, feel free to reopen.

-- 
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] #2879: Add live test server support to test framework

[Django]

#2879: Add live test server support to test framework
-+-
 Reporter:  Mikeal Rogers|Owner:  devin
   |   Status:  new
 Type:  New feature  |  Version:
Component:  Testing framework|   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 julien):

 I've converted the tests to using WebDriver in Firefox (tested) and IE
 (untested). Would anyone with a Windows environment be keen to try it out?
 :)

 WebDriver indeed has a number of advantages. It's faster to run, requires
 less boilerplate code, has a nicer Python API, and doesn't require to run
 the Java RC server in parallel.

 But it does also have a number of downsides. In particular it only
 supports Python 2.6 & 2.7, and some drivers (e.g. Chrome:
 http://code.google.com/p/selenium/wiki/ChromeDriver) are still lacking in
 functionality.

 I think that's ok, though. The lacking drivers will catch up and Django is
 likely going to drop Python 2.5 support in the near future.

 I've moved the base class (`AdminSeleniumWebDriverTestCase`) for the admin
 tests to `contrib/admin/tests.py`. You will also notice that the core of
 Django now doesn't contain any trace of Selenium and that the code for the
 RC flavour of Selenium present in previous patches has been removed. The
 approach here is similar with that of the one used for jQuery. Selenium
 and jQuery are both used by the admin, which in itself does represent a
 sort of "blessing", but this doesn't promote either of them as the one
 true way of handling respectively functional tests and dynamic interfaces
 in Django. This is partially to remain agnostic in regards to other
 frameworks and libraries, partially to avoid increasing the maintenance
 burden in Django core, and partially to make room for third party apps to
 develop more features around Selenium support. Again, 90% of the work is
 done by the built-in, generic, `LiveServerTestCase`. Enabling Selenium in
 your test suite then becomes as simple as:

 {{{#!python
 from django.test import LiveServerTestCase
 from selenium.webdriver.firefox.webdriver import WebDriver

 class MySeleniumTests(LiveServerTestCase):

 def setUp(self):
 self.selenium = WebDriver()
 super(MySeleniumTests, self).setUp()

 def tearDown(self):
 super(MySeleniumTests, self).tearDown()
 self.selenium.quit()

 def test_blah(self):
 ...
 }}}

 Any further feedback 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] #16940: Generic relations should be mentioned on docs index

[Django]

#16940: Generic relations should be mentioned on docs index
-+-
 Reporter:  danielr  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Documentation|   Resolution:  fixed
 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 timo):

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


Comment:

 In [17111]:
 {{{
 #!CommitTicketReference repository="" revision="17111"
 Fixed #16940 - Added "Generic relations" to docs index; thanks danielr for
 the suggestion.
 }}}

-- 
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] r17111 - django/trunk/docs

[noreply]

Author: timo
Date: 2011-11-19 03:38:40 -0800 (Sat, 19 Nov 2011)
New Revision: 17111

Modified:
   django/trunk/docs/index.txt
Log:
Fixed #16940 - Added "Generic relations" to docs index; thanks danielr for the 
suggestion.

Modified: django/trunk/docs/index.txt
===
--- django/trunk/docs/index.txt 2011-11-19 10:57:59 UTC (rev 17110)
+++ django/trunk/docs/index.txt 2011-11-19 11:38:40 UTC (rev 17111)
@@ -170,7 +170,7 @@
 * :doc:`Clickjacking protection `
 * :doc:`Comments ` | :doc:`Moderation 
` | :doc:`Custom comments 
`
 * :doc:`Conditional content processing `
-* :doc:`Content types `
+* :doc:`Content types and generic relations `
 * :doc:`Cross Site Request Forgery protection `
 * :doc:`Cryptographic signing `
 * :doc:`Databrowse `

-- 
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] #17105: Grammar errors in documentation

[Django]

#17105: Grammar errors in documentation
-+-
 Reporter:  googol   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  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 [17109]:
 {{{
 #!CommitTicketReference repository="" revision="17109"
 Fixed #17105 - Typos in docs/ref/contrib/csrf.txt; thanks googol for the
 report.
 }}}

-- 
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] #17196: Typo on staticfiles page

[Django]

#17196: Typo on staticfiles page
---+
 Reporter:  caa|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:
 Severity:  Normal |   Resolution:  fixed
 Keywords:  Typo   | Triage Stage:  Accepted
Has patch:  0  |  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 [17110]:
 {{{
 #!CommitTicketReference repository="" revision="17110"
 Fixed #17196 - Typo in docs/ref/contrib/staticfiles.txt; thanks caa for
 the report.
 }}}

-- 
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] r17110 - django/trunk/docs/ref/contrib

[noreply]

Author: timo
Date: 2011-11-19 02:57:59 -0800 (Sat, 19 Nov 2011)
New Revision: 17110

Modified:
   django/trunk/docs/ref/contrib/staticfiles.txt
Log:
Fixed #17196 - Typo in docs/ref/contrib/staticfiles.txt; thanks caa for the 
report.

Modified: django/trunk/docs/ref/contrib/staticfiles.txt
===
--- django/trunk/docs/ref/contrib/staticfiles.txt   2011-11-19 10:53:26 UTC 
(rev 17109)
+++ django/trunk/docs/ref/contrib/staticfiles.txt   2011-11-19 10:57:59 UTC 
(rev 17110)
@@ -365,7 +365,7 @@
 
 .. versionadded:: 1.4
 
-Uses the configued :setting:`STATICFILES_STORAGE` storage to create the
+Uses the configured :setting:`STATICFILES_STORAGE` storage to create the
 full URL for the given relative path, e.g.:
 
 .. 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.

[Changeset] r17109 - django/trunk/docs/ref/contrib

[noreply]

Author: timo
Date: 2011-11-19 02:53:26 -0800 (Sat, 19 Nov 2011)
New Revision: 17109

Modified:
   django/trunk/docs/ref/contrib/csrf.txt
Log:
Fixed #17105 - Typos in docs/ref/contrib/csrf.txt; thanks googol for the report.

Modified: django/trunk/docs/ref/contrib/csrf.txt
===
--- django/trunk/docs/ref/contrib/csrf.txt  2011-11-18 22:54:24 UTC (rev 
17108)
+++ django/trunk/docs/ref/contrib/csrf.txt  2011-11-19 10:53:26 UTC (rev 
17109)
@@ -347,8 +347,9 @@
 CsrfViewMiddleware.process_view not used
 
 
-There are cases when may not have run before your view is run - 404 and 500
-handlers, for example - but you still need the CSRF token in a form.
+There are cases when ``CsrfViewMiddleware.process_view``` may not have run
+before your view is run - 404 and 500 handlers, for example - but you still
+need the CSRF token in a form.
 
 Solution: use :func:`~django.views.decorators.csrf.requires_csrf_token`
 
@@ -420,7 +421,7 @@
 easily allowing cross-subdomain requests to be excluded from the normal cross
 site request forgery protection.  It should be set to a string such as
 ``".lawrence.com"`` to allow a POST request from a form on one subdomain to be
-accepted by accepted by a view served from another subdomain.
+accepted by a view served from another subdomain.
 
 Please note that, with or without use of this setting, this CSRF protection
 mechanism is not safe against cross-subdomain attacks -- see `Limitations`_.

-- 
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] #17250: Running unit test based on example tests.py not working

[Django]

#17250: Running unit test based on example tests.py not working
---+--
 Reporter:  social@…   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.3
 Severity:  Normal |   Resolution:  worksforme
 Keywords:  Test   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by russellm):

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


Comment:

 Hi Tobi,

 I'm going to mark this ticket as worksforme for the moment. I can't
 reproduce this problem, and I haven't seen anything like it in many years
 of running Django test suites.

 If you want help diagnosing this problem, please ask on the django-users
 mailing list. Trac isn't a help or support forum -- it's a way for us to
 track known problems with Django and make sure they get fixed. If the
 discussion on django-users reveals that something is actually wrong with
 Django (or that we need to document some special condtion), we can reopen
 this ticket to track the actual 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] #17259: error in http post data parser

[Django]

#17259: error in http post data parser
---+
 Reporter:  bayazee@…  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  HTTP handling  |Version:
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Traceback (most recent call last):

   File "/usr/local/lib/python2.6/site-
 packages/django/core/handlers/base.py", line 95, in get_response
 response = middleware_method(request, callback, callback_args,
 callback_kwargs)

   File "/usr/local/lib/python2.6/site-packages/django/middleware/csrf.py",
 line 164, in process_view
 request_csrf_token = request.POST.get('csrfmiddlewaretoken', "")

   File "/usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py", line 171, in _get_post
 self._load_post_and_files()

   File "/usr/local/lib/python2.6/site-
 packages/django/core/handlers/wsgi.py", line 137, in _load_post_and_files
 self._post, self._files = self.parse_file_upload(self.META,
 self.environ['wsgi.input'])

   File "/usr/local/lib/python2.6/site-packages/django/http/__init__.py",
 line 123, in parse_file_upload
 parser = MultiPartParser(META, post_data, self.upload_handlers,
 self.encoding)

   File "/usr/local/lib/python2.6/site-
 packages/django/http/multipartparser.py", line 80, in __init__
 raise MultiPartParserError("Invalid content length: %r" %
 content_length)

 MultiPartParserError: Invalid content length: 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] #17251: select_for_update tests threads should close connections manually

[Django]

#17251: select_for_update tests threads should close connections manually
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Uncategorized|   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 akaariai):

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


Comment:

 The GCed part of the description is somewhat wrong. Threadlocals do not
 get GCed when the thread goes away. However it seems they do get GCed if
 the thread has gone away and _another_ thread is then accessing the same
 thread-local object. Or at least this is my working hypothesis based on
 the fact that the connection gets closed on this line in the
 transactions.py, managed() [L111]:
 {{{
  connection.managed(flag)
 }}}

 And this is ran from main thread! I assume this is the first time the
 default_db_alias' DatabaseWrapper object (which is thread-local) is used
 after the another thread has gone away. I assume Python GCes the state of
 the other thread because it has gone away, and it sees it only when the
 object is accessed.

 If you want to try tracking this down, I have a branch where you can run:
 {{{
 python runtests.py --settings=test_pgsql
 select_for_update.SelectForUpdateTests.test_nowait_raises_error_on_block
 }}}
 Then wait until you get into PDB. Begin stepping through the code. Note
 when the 'I got deleted' for thread 1 is printed. Note also which thread
 you are currently in. It is also good to use postgresql and set
 log_connections / log_disconnections to ON, and also log at least the
 backend pid in the log_line_prefix (%p).

 I think this enforces the point that it would be good to close the
 connection in the tester threads. The current behavior seems to be based
 on pure luck :) I am also beginning to see why some of the core developers
 don't like thread-locals...

 The test code for this is at:
 https://github.com/akaariai/django/tree/connection_close

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