date:20111120

Re: [Django] #2879: Add live test server support to test framework

2011-11-20 Thread 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):

 Thanks, Tom, those tests are very useful!

 (By the way, there seems to be a problem with your latest patch as it
 didn't apply cleanly with 'git apply'. I had to use the 'patch -p1'
 command and then manually create the `live_server_tests/__init__.py` file)

 The process termination issue is a weird one. It seems to only occur with
 Python 2.7, as it works fine with Python 2.5&6. Also, adding
 `sleep(0.001)` at the end of `LiveServerTestCase.tearDown()` seems to fix
 it — although that wouldn't be acceptable as a solution :)

 Threads cannot easily share memory in Python. Pysqlite addresses that
 problem by setting the `check_same_thread` parameter to `False`:
 `sqlite.connect(":memory:", check_same_thread = False)`

 So, instead of recreating a new database in the separate thread, we should
 make sqlite share the same in-memory database by setting
 `DATABASES['default']['OPTIONS']['check_same_thread']` to False in
 `LiveServerTestCase.setUp()`. I haven't tested that yet. You can google
 'check_same_thread' for more info — some people claim that it works and
 others that it doesn't. If no solution can be found then it looks like in-
 memory sqlite databases might not be supported by this approach.

 As for the media, it's unclear to me from looking at your patch what
 you're actually testing. Where are the "example_media_file.txt" and
 "example_file.txt" files supposed to be physically located and served
 from?

-- 
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] #17213: Can't change TIME_ZONE after initial transaction in PostgreSQL

2011-11-20 Thread Django

#17213: Can't change TIME_ZONE after initial transaction in PostgreSQL
-+-
 Reporter:  calvinspealman   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 In fact, you're looking a larger problem than just time zone settings.
 (Massive) multi-hosting isn't supported by Django at this time. While it
 sort of works (some third party libraries exist to support this use case),
 our current position is that changing settings at runtime may cause
 undefined behavior.

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

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

Re: [Django] #17268: r17119 broke the cache tests under PostgreSQL on the CI server

2011-11-20 Thread Django

#17268: r17119 broke the cache tests under PostgreSQL on the CI server
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Core (Cache system)  |  Version:
 Severity:  Release blocker  |   Resolution:  fixed
 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):

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


Comment:

 In [17131]:
 {{{
 #!CommitTicketReference repository="" revision="17131"
 Fixed #17268 -- Two failures in the cache 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] r17131 - django/trunk/tests/regressiontests/cache

2011-11-20 Thread noreply

Author: aaugustin
Date: 2011-11-20 23:08:39 -0800 (Sun, 20 Nov 2011)
New Revision: 17131

Modified:
   django/trunk/tests/regressiontests/cache/tests.py
Log:
Fixed #17268 -- Two failures in the cache tests.


Modified: django/trunk/tests/regressiontests/cache/tests.py
===
--- django/trunk/tests/regressiontests/cache/tests.py   2011-11-21 06:07:24 UTC 
(rev 17130)
+++ django/trunk/tests/regressiontests/cache/tests.py   2011-11-21 07:08:39 UTC 
(rev 17131)
@@ -22,7 +22,7 @@
 UpdateCacheMiddleware, CacheMiddleware)
 from django.template import Template
 from django.template.response import TemplateResponse
-from django.test import TestCase, RequestFactory
+from django.test import TestCase, TransactionTestCase, RequestFactory
 from django.test.utils import (get_warnings_state, restore_warnings_state,
 override_settings)
 from django.utils import timezone, translation, unittest
@@ -746,7 +746,7 @@
 return 'CUSTOM-' + '-'.join([key_prefix, str(version), key])
 
 
-class DBCacheTests(BaseCacheTests, TestCase):
+class DBCacheTests(BaseCacheTests, TransactionTestCase):
 backend_name = 'django.core.cache.backends.db.DatabaseCache'
 
 def setUp(self):

-- 
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] #17252: Multi-sort in admin does not respect initial admin_order_field

2011-11-20 Thread Django

#17252: Multi-sort in admin does not respect initial admin_order_field
-+-
 Reporter:  sebastian|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:  multi-sort, admin,   | Triage Stage:  Accepted
  ordering   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  1
Easy pickings:  1|
-+-

Comment (by sebastian):

 Thanks for the feedback. I revised the test so that it makes use of the
 `ChangeList` instance in the response's context, as you suggested. This
 should make it robust with regard to changes in the admin's HTML markup.
 It also makes an explicit check for the actual column selected.

-- 
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] #5805: Specify multicolumn indexes.

2011-11-20 Thread Django

#5805: Specify multicolumn indexes.
-+-
 Reporter:  Stavros  |Owner:  jgelens
  Korokithakis    |   Status:  assigned
 Type:  New feature  |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  index multicolumn|  Patch needs improvement:  0
  indexes database dceu2011  |UI/UX:  0
Has patch:  1|
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by gvangool):

 * cc: gert.vangool@… (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] #16220: Add introspection for multicolumn indexes

2011-11-20 Thread Django

#16220: Add introspection for multicolumn indexes
-+-
 Reporter:  jgelens  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:  dceu2011 inspectdb   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by gvangool):

 * cc: gert.vangool@… (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] #17269: Fix model options docs with regard to admin multi-sort

2011-11-20 Thread Django

#17269: Fix model options docs with regard to admin multi-sort
-+-
 Reporter:  sebastian|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  docs, multi-sort,|  Needs documentation:  0
  admin, model, options  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by julien):

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


Comment:

 In [17130]:
 {{{
 #!CommitTicketReference repository="" revision="17130"
 Fixed #17269 -- Corrected the model options doc to indicate that, since
 1.4, all fields in `Meta.ordering` are honored by the admin. Thanks to
 sebastian for the report and patch.
 }}}

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

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

[Changeset] r17130 - django/trunk/docs/ref/models

2011-11-20 Thread noreply

Author: julien
Date: 2011-11-20 22:07:24 -0800 (Sun, 20 Nov 2011)
New Revision: 17130

Modified:
   django/trunk/docs/ref/models/options.txt
Log:
Fixed #17269 -- Corrected the model options doc to indicate that, since 1.4, 
all fields in `Meta.ordering` are honored by the admin. Thanks to sebastian for 
the report and patch.

Modified: django/trunk/docs/ref/models/options.txt
===
--- django/trunk/docs/ref/models/options.txt2011-11-20 20:43:59 UTC (rev 
17129)
+++ django/trunk/docs/ref/models/options.txt2011-11-21 06:07:24 UTC (rev 
17130)
@@ -189,11 +189,6 @@
 "-" prefix, which indicates descending order. Fields without a leading "-" 
will
 be ordered ascending. Use the string "?" to order randomly.
 
-.. note::
-
-Regardless of how many fields are in :attr:`~Options.ordering`, the 
admin
-site uses only the first field.
-
 For example, to order by a ``pub_date`` field ascending, use this::
 
 ordering = ['pub_date']
@@ -206,6 +201,10 @@
 
 ordering = ['-pub_date', 'author']
 
+.. versionchanged:: 1.4
+   The Django admin honors all elements in the list/tuple; before 1.4, only
+   the first one was respected.
+
 ``permissions``
 ---
 

-- 
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] #17252: Multi-sort in admin does not respect initial admin_order_field

2011-11-20 Thread Django

#17252: Multi-sort in admin does not respect initial admin_order_field
-+-
 Reporter:  sebastian|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:  multi-sort, admin,   | Triage Stage:  Accepted
  ordering   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  1
Easy pickings:  1|
-+-
Changes (by julien):

 * severity:  Normal => Release blocker


Comment:

 Replying to [comment:5 sebastian]:
 > Sure, making `ordering` more explicit would be nice but IMHO that's
 outside the scope of this ticket. Here, I'm only concerned with the
 regression introduced by the multi-sort addition to the admin which causes
 the initial sort indicator icons to not show up under certain
 circumstances, i.e. whenever something is sorted with `admin_order_field`.
 >
 > This bug is not a functional issue per se, but hiding those icons when
 the admin change list is actually sorted (which it is) is kind of
 misleading to the user.

 I confirm that this is a regression, thus marking as blocker. It's ok to
 address only that regression in this ticket.

 > Regarding the proposition of making `ordering` more explicit, I suggest
 opening a new ticket for that and keeping this one for the regression at
 hand. Some questions arise, however, how far this more explicit `ordering`
 should reach: should method names also be allowed in models, ie. not only
 model admins?
 > ... snip ...

 Yes, a separate ticket could be opened for that. `ModelAdmin.ordering`
 should accept exactly the same options as `ModelAdmin.list_display`, i.e.
 field names or `ModelAdmin` methods or `Model` methods that have a
 `admin_ordering_field` pointing to an actual model field.

 The patch looks good. The tests, however, don't seem to check which column
 is actually sorted. They're also a bit fragile as they're testing HTML
 code (i.e. '`class="sortable sorted ascending"`') which is always a bit
 volatile in the admin templates. I think the tests could be made a little
 more explicit and less fragile by testing the context value of
 `cl.get_ordering_field_columns()`. Could you make that change before we
 proceed? 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] #14952: New find_commands(management_dir) to support .pyc and .pyo

2011-11-20 Thread Django

#14952: New find_commands(management_dir) to support .pyc and .pyo
---+--
 Reporter:  lgx@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Core (Other)   |  Version:  1.2
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  find_commands  | 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:

 Do you have a source for "executing Python bytecode only files is
 gradually being removed from CPython"? There are no PEPs pertaining to
 removing the bytecode generation step for CPython.

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

2011-11-20 Thread 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):

 Made a start on some extra tests...

 {{{
 ./runtests.py --settings=test_sqlite live_server_tests
 }}}

 1. As mentioned media files not served when `MEDIA_URL` and `MEDIA_ROOT`
 set. (`test_media_files` fails).  Not 100% sure what the behavior ought to
 be here.
 2. When running with in-memory database, database changes made in live
 server thread are not visible in test thread. (`test_database_writes`
 fails)... ...I'd assume(?) that'd pass on a proper database (not had time
 to test.)
 3. When running with sqlite database using TEST_NAME in database settings,
 everything always hangs after "would you like to try deleting the test
 database" prompt.
 4. Multiple databases not yet supported? (not written a test for this
 yet.)  Looks easy to fix.
 5. Process termination problem mentioned before can occur (Eg run
 `./runtests.py --settings=test_sqlite
 live_server_tests.TestViews.test_view`)

-- 
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] #17271: QuerySet.none() doesn't work well with subclasses of QuerySet

2011-11-20 Thread Django

#17271: QuerySet.none() doesn't work well with subclasses of QuerySet
-+-
 Reporter:  andreypopp   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by andreypopp):

 * cc: 8mayday@… (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] #17271: QuerySet.none() doesn't work well with subclasses of QuerySet

2011-11-20 Thread Django

#17271: QuerySet.none() doesn't work well with subclasses of QuerySet
-+-
 Reporter:  andreypopp   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by andreypopp):

 * needs_better_patch:   => 0
 * type:  Bug => New feature
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #17271: QuerySet.none() doesn't work well with subclasses of QuerySet

2011-11-20 Thread Django

#17271: QuerySet.none() doesn't work well with subclasses of QuerySet
--+
 Reporter:  andreypopp|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  1 |  UI/UX:  0
--+
 I use `QuerySet` subclassing to allow building complex composable queries
 out of smaller ones:
 {{{
 class MyQuerySet(QuerySet):
   def allowed(self, user):
 return self.filter(permissions__in=user.permissions)

   def have_feature(feature_name):
 return self.filter(feature__name=feature_name)
 ...

 objs = Obj.objects.allowed(user).have_feature("somefeature")
 }}}

 Sometimes I want to return `EmptyQuerySet` by calling `none()` to provide
 "fast-path" for some conditions, but unfortunately `EmptyQuerySet` doesn't
 have my custom methods, so call chain breaks after returning it:

 {{{
 class MyQuerySet(QuerySet):
   def allowed(self, user):
 if user.is_anonymous:
   return self.none()
 return self.filter(permissions__in=user.permissions)

   def have_feature(feature_name):
 return self.filter(feature__name=feature_name)
 ...

 objs = Obj.objects.allowed(user).have_feature("some feature")
 # AttributeError: EmptyQuerySet doesn't have have_feature attribute ...
 }}}

 I've attached a patch which instruments `EmptyQuerySet` subclass for each
 particular `QuerySet` implementation and returns its instance as a result
 of `none()` method call. I've also refactored code in `Manager.none()` to
 reuse existing code in `QuerySet.none()` and to parametrize `Manager()`
 constructor over `QuerySet` implementation to use.

-- 
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] #17270: methods of the manager on subqueries QuerySet objects

2011-11-20 Thread Django

#17270: methods of the manager on subqueries QuerySet objects
-+-
 Reporter:  Wojciech Banaś   |  Owner:  fizista@…
  | Status:  new
 Type:  New feature  |Version:
Component:  Database layer   |   Keywords:  queryset manager
  (models, ORM)  |  Extends
 Severity:  Normal   |  Has patch:  1
 Triage Stage:  Unreviewed   |  UI/UX:  0
Easy pickings:  0|
-+-
 Extends the operation methods of the manager on subqueries QuerySet
 objects.

 The "standard manager" you can only like this:

 {{{
 SomeModel.object.some_method_manager().all().filter(...). ...
 }}}


 But this does not work:

 {{{
 SomeModel.object.all().some_method_manager()
 }}}

 And this it works with the use of this class / patches:

 {{{
 
SomeModel.object.all().some_method_manager().filter(...).some_method_manager2().
 ...
 
SomeModel.object.some_method_manager().some_method_manager2().some_method_manager3().
 ...
 }}}

 Extension of the methods manager on all child objects "QuerySeth".

 Example:

 * class model
 {{{
 class Animals(models.Model):
 type = models.CharField('Type of animal') # dog, cat, elephant
 color = models.CharField('Colour Name')

 objects = AnimalsManager()
 }}}

 * class manager

 {{{
 class AnimalsManager(ManagerQuerySetDecorator):

 def get_dogs(self):
 return self.get_query_set().filter(type='dog')
 get_dogs.queryset_method = True

 def get_cats(self):
 return self.get_query_set().filter(type='cat')
 get_cats.queryset_method = True

 def get_white_animals(self):
 return self.get_query_set().filter(color='white')
 get_white_animals.queryset_method = True

 def get_black_animals(self):
 return self.get_query_set().filter(color='black')
 get_black_animals.queryset_method = True

 def get_brown_animals(self):
 return self.get_query_set().filter(color='black')

 }}}

 * add models data

 {{{
 Animals(type='dog', color='black').save()
 Animals(type='dog', color='bown').save()
 Animals(type='dog', color='white').save()
 Animals(type='cat', color='black').save()
 Animals(type='cat', color='bown').save()
 Animals(type='cat', color='white').save()

 }}}

 * examples of actions a new manager

 {{{
 animals = Animals.objects.get_black_animals().get_dogs()
 # return list black dogs

 animals = Animals.objects.get_white_animals().get_cats()
 # return list white cats

 # When  equals False, or not defined (as it is in
 # the original model manager), we can not perform such an operation:
 animals = Animals.objects.get_cats().get_brown_animals()
 # return:
 # AttributeError: 'QuerySet' object has no attribute
 'get_brown_animals'

 # but:
 animals = Animals.objects.get_brown_animals().get_cats()
 # return brown cats, because get_cat() present in all parent object
 instances.
 }}}

 In Annex file a class action extends the manager.

 If there is interest in this patch, then add in the future full of tests,
 and prepare a ready-made patch for django code.

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

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

Re: [Django] #17213: Can't change TIME_ZONE after initial transaction in PostgreSQL

2011-11-20 Thread Django

#17213: Can't change TIME_ZONE after initial transaction in PostgreSQL
-+-
 Reporter:  calvinspealman   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by calvinspealman):

 While I'm very happy to see #2626 moving forward, I don't think it will be
 helpful in the context I've seen #17213 needed, which are installations
 running more sites than can realistically be served with at least one
 process per site, and some sort of middleware is used before each request
 to load per-site settings. I understand the dislike of changing settings,
 and I agree with it. i only filed this ticket, because it seemed that
 #3459 had broken a previous behavior and I could not determine if this was
 intended or desirable. I'm not sure the best course of action for such
 setups in the future, but will give it some thought.

-- 
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] #17269: Fix model options docs with regard to admin multi-sort

2011-11-20 Thread Django

#17269: Fix model options docs with regard to admin multi-sort
-+-
 Reporter:  sebastian|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  docs, multi-sort,|  Needs documentation:  0
  admin, model, options  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by sebastian):

 krzysiumed, I'm confused. I did, in fact, run `svn diff` from the root, as
 the file name in the patch indicates: `docs/ref/models/options.txt`. Just
 to double-check, I re-ran it and now I'm 100 % certain that I did indeed
 run it from the root (i.e. `trunk`), as it reproduces the exact same patch
 file. What's wrong with the file I attached?

 Regarding the inline vs. block issue with `versionchanged` – is there a
 consensus as to when to inline the change comment? About half of the
 `versionchanged` comments in the current docs are inlined, the other half
 is blocked. (In fact, the corresponding section in [16316] uses the block
 notation in `docs/ref/contrib/admin/index.txt`.)

 Anyway, I'm attaching an updated patch with the `versionchanged` note
 inlined. This time I'm 100 % certain that I did run `svn diff` from the
 root directory, i.e. parent of `docs`.

-- 
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] #17269: Fix model options docs with regard to admin multi-sort

2011-11-20 Thread Django

#17269: Fix model options docs with regard to admin multi-sort
-+-
 Reporter:  sebastian|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  docs, multi-sort,|  Needs documentation:  0
  admin, model, options  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by krzysiumed):

 And use
 {{{
 .. versionchanged:: 1.4
The Django admin honors all elements in the list/tuple ...
 }}}
 instead of
 {{{
 .. versionchanged:: 1.4

The Django admin honors all elements in the list/tuple ...
 }}}
 please.

-- 
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] #17269: Fix model options docs with regard to admin multi-sort

2011-11-20 Thread Django

#17269: Fix model options docs with regard to admin multi-sort
-+-
 Reporter:  sebastian|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  docs, multi-sort,|  Needs documentation:  0
  admin, model, options  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by krzysiumed):

 sebastian, please run 'svn diff' command when you are in main directory of
 django (parent of 'docs' directory).

-- 
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] #17269: Fix model options docs with regard to admin multi-sort

2011-11-20 Thread Django

#17269: Fix model options docs with regard to admin multi-sort
-+-
 Reporter:  sebastian|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  docs, multi-sort,|  Needs documentation:  0
  admin, model, options  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by krzysiumed):

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


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

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

Re: [Django] #16851: Accessing a forms field value in a template

2011-11-20 Thread Django

#16851: Accessing a forms field value in a template
-+-
 Reporter:  from_a_far@… |Owner:
 Type:  Uncategorized|  yasar11732
Component:  Documentation|   Status:  assigned
 Severity:  Normal   |  Version:  1.3
 Keywords:   |   Resolution:
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  1|  Needs documentation:  0
 |  Patch needs improvement:  1
 |UI/UX:  0
-+-
Changes (by krzysiumed):

 * stage:  Accepted => Ready for checkin


-- 
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] #16758: Documentation for TEMPLATE_CONTEXT_PROCESSORS could use additional warning.

2011-11-20 Thread Django

#16758: Documentation for TEMPLATE_CONTEXT_PROCESSORS could use additional 
warning.
-+-
 Reporter:  cyclops  |Owner:
 Type:   |  yasar11732
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by krzysiumed):

 The beginning of the warning is:
   Be careful with the settings in settings.py, because settings in
 settings.py override the default values.  Overriding some settings may
 cause ...
 Word 'settings' is repeated and repeated. I suggest changing it to
 something like this
   Be careful when you override default values of settings, because it may
 cause ...

 [[br]]
 Next, there is
   ... may cause some core or commonly used functions of Django to stop
 functioning ...
 I'm not sure 'functioning' is good word. I prefer simpler words, for
 example:
   ... may cause some core or commonly used functions of Django to stop
 working correctly ...

 [[br]]
 yasar11732, you wrote
   When overriding default values, you are advised to make sure that none
 of the functions of Django that you need requires previous setting to work
 correctly.
 Are there features of Django that cannot work correctly with non default
 values of some settings? I'm asking because I'm new contributor and i
 don't know everything about Django.

 [[br]]
   If the setting you are trying to change consists of more than one value
 (e.g a tuple), ...
 I suggest
   If the setting you want to change is tuple, list or dictonary, ...
 because there are more words 'want' than 'try' in tutorial. I'm not sure
 if 'is tuple, list or directory' is more clear than 'consists of more than
 one value'.

-- 
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] #8798: Add DEPhoneNumberField to German localflavor module

2011-11-20 Thread Django

#8798: Add DEPhoneNumberField to German localflavor module
-+
 Reporter:  jezdez   |Owner:  jezdez
 Type:  New feature  |   Status:  reopened
Component:  contrib.localflavor  |  Version:  SVN
 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:  1
-+
Changes (by aaugustin):

 * status:  closed => reopened
 * severity:  Release blocker => Normal
 * type:  Bug => New feature
 * component:  contrib.admindocs => contrib.localflavor
 * keywords:  acthucje =>
 * resolution:  invalid =>
 * stage:  Design decision needed => Accepted


Comment:

 Revert spam.

-- 
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] r17129 - django/trunk/tests/regressiontests/backends

2011-11-20 Thread noreply

Author: aaugustin
Date: 2011-11-20 12:43:59 -0800 (Sun, 20 Nov 2011)
New Revision: 17129

Modified:
   django/trunk/tests/regressiontests/backends/tests.py
Log:
Tweaked the skipping condition for the test introduced in r17128 so that it 
works on non-PostgreSQL backends.


Modified: django/trunk/tests/regressiontests/backends/tests.py
===
--- django/trunk/tests/regressiontests/backends/tests.py2011-11-20 
16:12:33 UTC (rev 17128)
+++ django/trunk/tests/regressiontests/backends/tests.py2011-11-20 
20:43:59 UTC (rev 17129)
@@ -235,10 +235,9 @@
 #17062: PostgreSQL shouldn't roll back SET TIME ZONE, even if the first
 transaction is rolled back.
 """
-@unittest.skipUnless(connection.vendor == 'postgresql',
- "Test valid only for PostgreSQL")
-@unittest.skipUnless(connection.isolation_level > 0,
- "Test valid only if not using autocommit")
+@unittest.skipUnless(
+connection.vendor == 'postgresql' and connection.isolation_level > 0,
+"This test applies only to PostgreSQL without autocommit")
 def test_connect_and_rollback(self):
 new_connections = ConnectionHandler(settings.DATABASES)
 new_connection = new_connections[DEFAULT_DB_ALIAS]

-- 
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] #8798: Add DEPhoneNumberField to German localflavor module

2011-11-20 Thread Django

#8798: Add DEPhoneNumberField to German localflavor module
-+-
 Reporter:  jezdez   |Owner:  jezdez
 Type:  Bug  |   Status:  closed
Component:  contrib.admindocs|  Version:  SVN
 Severity:  Release blocker  |   Resolution:  invalid
 Keywords:  acthucje | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  1
-+-
Changes (by iprcfdbmrz):

 * status:  new => closed
 * severity:  Normal => Release blocker
 * type:  New feature => Bug
 * component:  contrib.localflavor => contrib.admindocs
 * keywords:   => acthucje
 * resolution:   => invalid
 * stage:  Accepted => Design decision needed


Comment:

 kbhjzdpef, http://www.hkgizcltwq.com;>qawtiuqbib ,
 [url=http://www.cobmmvvqnl.com]nfwurdpjii[/url], http://www.rtqaqkhetd.com
 qawtiuqbib

-- 
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] #8798: Add DEPhoneNumberField to German localflavor module

2011-11-20 Thread Django

#8798: Add DEPhoneNumberField to German localflavor module
-+-
 Reporter:  jezdez   |Owner:  jezdez
 Type:  Bug  |   Status:  closed
Component:  contrib.admindocs|  Version:  SVN
 Severity:  Release blocker  |   Resolution:  invalid
 Keywords:  acthucje | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  1
-+-
Changes (by iprcfdbmrz):

 * status:  new => closed
 * severity:  Normal => Release blocker
 * type:  New feature => Bug
 * component:  contrib.localflavor => contrib.admindocs
 * keywords:   => acthucje
 * resolution:   => invalid
 * stage:  Accepted => Design decision needed


Comment:

 kbhjzdpef, http://www.hkgizcltwq.com;>qawtiuqbib ,
 [url=http://www.cobmmvvqnl.com]nfwurdpjii[/url], http://www.rtqaqkhetd.com
 qawtiuqbib

-- 
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] #16916: Please document django.test.Client.defaults

2011-11-20 Thread Django

#16916: Please document django.test.Client.defaults
--+
 Reporter:  sailorfred@…  |Owner:  raulcd
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by krzysiumed):

 * needs_better_patch:  0 => 1


Comment:

 I think lines 694-695 are too deep - the indentation should be one level
 of depth (see deleted lines 672-673 in your patch).

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

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

Re: [Django] #17266: psycopg2 backend should use get_parameter_status to check if SET TIME ZONE is needed

2011-11-20 Thread Django

#17266: psycopg2 backend should use get_parameter_status to check if SET TIME 
ZONE
is needed
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

 * has_patch:  0 => 1
 * type:  Uncategorized => Cleanup/optimization


Comment:

 Provided is a patch that does use get_parameter_status to sniff the
 connection's default time zone. I did a little testing of this. Queries
 generated for a new connection with patch (using psycopg2 version 2.4.2):
 {{{
 21335: LOG:  connection authorized: user=akaj database=testdb1
 21335: LOG:  statement: SHOW default_transaction_isolation
 21335: LOG:  statement: BEGIN
 21335: LOG:  statement: first real query
 }}}
 Without patch:
 {{{
 21355: LOG:  connection authorized: user=akaj database=testdb1
 21355: LOG:  statement: SHOW default_transaction_isolation
 21355: LOG:  statement: SET default_transaction_isolation TO DEFAULT
 21355: LOG:  statement: SET TIME ZONE 'America/Chicago'
 21355: LOG:  statement: SET default_transaction_isolation TO 'read
 committed'
 21355: LOG:  statement: BEGIN
 21355: LOG:  statement: first real query...
 }}}

 The precondition for this is that the connections default time zone is
 actually the wanted timezone (settings TIME_ZONE if not USE_TZ, else UTC).
 Attached patch contains some documentation mentioning that it is a good
 idea to have the database or user defaults as mentioned above. Also, I
 think you will need psycopg2 version 2.4.2 or later
 ([http://initd.org/psycopg/articles/2011/06/12/psycopg-242-released/|see
 release notes]) or you will get more queries than in the examples posted
 above. The patch should work with all versions of psycopg2, though.

 The speed difference for making single query and then disconnecting is
 about 10% on a localhost database. It would be likely more if the database
 was on another machine, as there is no TCP/IP overhead for localhost
 connections. The test was:
 {{{
 start = datetime.now()
 for i in range(0, 1):
 list(SomeModel.objects.all()) # no rows in the DB, so this is very
 lightweight query.
 connection.close()
 print datetime.now() - start
 }}}

 So, there is some gain from this.

 I have guarded against psycopg2 versions not having get_parameter_status
 in the patch (versions prior to 2.0.12).

 I don't see any easy way to test if you actually get less queries -
 psycopg2 will not report all the internal queries made. Manually it is
 easy to test: just set log_statement to 'all' and log_connections to on in
 postgresql.conf (or for the db user) and see PostgreSQL's log to check
 what queries are made.

 I haven't build the documentation, dunno if it really works. The
 reviewer/committer might want to check the language used in the
 documentation, my English isn't too good. Also, I haven't tested this on
 any other psycopg version than 2.4.2.

-- 
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] #14262: Helper for "get_something as varname" template tag pattern

2011-11-20 Thread Django

#14262: Helper for "get_something as varname" template tag pattern
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  contrib.admindocs|  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:  zctdthau | 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 njmzxduerw):

 * status:  closed => reopened
 * severity:  Normal => Release blocker
 * type:  New feature => Bug
 * component:  Template system => contrib.admindocs
 * keywords:   => zctdthau
 * ui_ux:   => 0
 * resolution:  fixed =>
 * stage:  Ready for checkin => Design decision needed


Comment:

 rldxodpef, http://www.zprycjhexk.com;>pjtdyqkcmv ,
 [url=http://www.xumolaanyj.com]rrgwptwgzz[/url], http://www.itfwqzukac.com
 pjtdyqkcmv

-- 
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] #14262: Helper for "get_something as varname" template tag pattern

2011-11-20 Thread Django

#14262: Helper for "get_something as varname" template tag pattern
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  contrib.admindocs|  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:  zctdthau | 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 njmzxduerw):

 * status:  closed => reopened
 * severity:  Normal => Release blocker
 * resolution:  fixed =>
 * component:  Template system => contrib.admindocs
 * keywords:   => zctdthau
 * ui_ux:   => 0
 * type:  New feature => Bug
 * stage:  Ready for checkin => Design decision needed


Comment:

 rldxodpef, http://www.zprycjhexk.com;>pjtdyqkcmv ,
 [url=http://www.xumolaanyj.com]rrgwptwgzz[/url], http://www.itfwqzukac.com
 pjtdyqkcmv

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

2011-11-20 Thread Django

#17261: Refactor parsing of date and times
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Uncategorized|   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|
-+-
Changes (by aaugustin):

 * 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] #17266: psycopg2 backend should use get_parameter_status to check if SET TIME ZONE is needed

2011-11-20 Thread Django

#17266: psycopg2 backend should use get_parameter_status to check if SET TIME 
ZONE
is needed
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:
  (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|
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * 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.

[Changeset] r17128 - in django/trunk: django/db/backends/postgresql_psycopg2 tests/regressiontests/backends

2011-11-20 Thread noreply

Author: aaugustin
Date: 2011-11-20 08:12:33 -0800 (Sun, 20 Nov 2011)
New Revision: 17128

Modified:
   django/trunk/django/db/backends/postgresql_psycopg2/base.py
   django/trunk/tests/regressiontests/backends/tests.py
Log:
Fixed #17062 -- Ensured that the effect of SET TIME ZONE isn't lost when the 
first transation is rolled back under PostgreSQL. Thanks Anssi for the patch.


Modified: django/trunk/django/db/backends/postgresql_psycopg2/base.py
===
--- django/trunk/django/db/backends/postgresql_psycopg2/base.py 2011-11-20 
15:34:08 UTC (rev 17127)
+++ django/trunk/django/db/backends/postgresql_psycopg2/base.py 2011-11-20 
16:12:33 UTC (rev 17128)
@@ -153,10 +153,8 @@
 pg_version = property(_get_pg_version)
 
 def _cursor(self):
-new_connection = False
 settings_dict = self.settings_dict
 if self.connection is None:
-new_connection = True
 if settings_dict['NAME'] == '':
 from django.core.exceptions import ImproperlyConfigured
 raise ImproperlyConfigured("You need to specify NAME in your 
Django settings file.")
@@ -176,15 +174,17 @@
 conn_params['port'] = settings_dict['PORT']
 self.connection = Database.connect(**conn_params)
 self.connection.set_client_encoding('UTF8')
+# Set the time zone in autocommit mode (see #17062)
+tz = 'UTC' if settings.USE_TZ else settings_dict.get('TIME_ZONE')
+if tz:
+self.connection.set_isolation_level(
+psycopg2.extensions.ISOLATION_LEVEL_AUTOCOMMIT)
+self.connection.cursor().execute("SET TIME ZONE %s", [tz])
 self.connection.set_isolation_level(self.isolation_level)
+self._get_pg_version()
 connection_created.send(sender=self.__class__, connection=self)
 cursor = self.connection.cursor()
 cursor.tzinfo_factory = utc_tzinfo_factory if settings.USE_TZ else None
-if new_connection:
-tz = 'UTC' if settings.USE_TZ else settings_dict.get('TIME_ZONE')
-if tz:
-cursor.execute("SET TIME ZONE %s", [tz])
-self._get_pg_version()
 return CursorWrapper(cursor)
 
 def _enter_transaction_management(self, managed):

Modified: django/trunk/tests/regressiontests/backends/tests.py
===
--- django/trunk/tests/regressiontests/backends/tests.py2011-11-20 
15:34:08 UTC (rev 17127)
+++ django/trunk/tests/regressiontests/backends/tests.py2011-11-20 
16:12:33 UTC (rev 17128)
@@ -10,6 +10,7 @@
 IntegrityError, transaction)
 from django.db.backends.signals import connection_created
 from django.db.backends.postgresql_psycopg2 import version as pg_version
+from django.db.utils import ConnectionHandler, DatabaseError
 from django.test import TestCase, skipUnlessDBFeature, TransactionTestCase
 from django.utils import unittest
 
@@ -229,6 +230,47 @@
 conn = OlderConnectionMock()
 self.assertEqual(pg_version.get_version(conn), 80300)
 
+class PostgresNewConnectionTest(TestCase):
+"""
+#17062: PostgreSQL shouldn't roll back SET TIME ZONE, even if the first
+transaction is rolled back.
+"""
+@unittest.skipUnless(connection.vendor == 'postgresql',
+ "Test valid only for PostgreSQL")
+@unittest.skipUnless(connection.isolation_level > 0,
+ "Test valid only if not using autocommit")
+def test_connect_and_rollback(self):
+new_connections = ConnectionHandler(settings.DATABASES)
+new_connection = new_connections[DEFAULT_DB_ALIAS]
+try:
+# Ensure the database default time zone is different than
+# the time zone in new_connection.settings_dict. We can
+# get the default time zone by reset & show.
+cursor = new_connection.cursor()
+cursor.execute("RESET TIMEZONE")
+cursor.execute("SHOW TIMEZONE")
+db_default_tz = cursor.fetchone()[0]
+new_tz = 'Europe/Paris' if db_default_tz == 'UTC' else 'UTC'
+new_connection.close()
+
+# Fetch a new connection with the new_tz as default
+# time zone, run a query and rollback.
+new_connection.settings_dict['TIME_ZONE'] = new_tz
+new_connection.enter_transaction_management()
+cursor = new_connection.cursor()
+new_connection.rollback()
+
+# Now let's see if the rollback rolled back the SET TIME ZONE.
+cursor.execute("SHOW TIMEZONE")
+tz = cursor.fetchone()[0]
+self.assertEqual(new_tz, tz)
+finally:
+try:
+new_connection.close()
+except DatabaseError:
+pass
+
+
 # Unfortunately with sqlite3 the

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

2011-11-20 Thread 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:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 In [17128]:
 {{{
 #!CommitTicketReference repository="" revision="17128"
 Fixed #17062 -- Ensured that the effect of SET TIME ZONE isn't lost when
 the first transation is rolled back under PostgreSQL. Thanks Anssi for the
 patch.
 }}}

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

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

[Django] #17269: Fix model options docs with regard to admin multi-sort

2011-11-20 Thread Django

#17269: Fix model options docs with regard to admin multi-sort
-+-
 Reporter:  sebastian|  Owner:  nobody
 Type:   | Status:  new
  Cleanup/optimization   |Version:  SVN
Component:  Documentation|   Keywords:  docs, multi-sort,
 Severity:  Normal   |  admin, model, options
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  1|  UI/UX:  0
-+-
 Since the recent introduction of the admin multi-sort addition,
 `contrib.admin` respects all fields specified on a model's `ordering`
 option. The docs should be updated to reflect this.

 Changeset [16316] added a corresponding notice to the admin docs and the
 release changes, but missed the explicit note regarding this in the model
 options documentation.

 The attached patch fixes this by updating that documentation as well.

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

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

Re: [Django] #17268: r17119 broke the cache tests under PostgreSQL on the CI server

2011-11-20 Thread Django

#17268: r17119 broke the cache tests under PostgreSQL on the CI server
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by apollo13):

 I can reproduce it with Debian unstable, Postgres 9.0.5 and psycopg
 2.4.2-1 -- The second cache.add in test_add fails due to a violated unique
 constraint (the same key already exists from the first add) and as a
 result of this the .get and .commit (in teardown) fails. I fixed it
 locally via the attached patch, but I am not sure if it's the correct way.

-- 
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] #17268: r17119 broke the cache tests under PostgreSQL on the CI server

2011-11-20 Thread Django

#17268: r17119 broke the cache tests under PostgreSQL on the CI server
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 The problem probably appeared as a consequence of the following changes:
 - I used a `django.test.TestCase` instead of a
 `django.utils.unittest.TestCase` because I wanted to apply the
 `override_settings` decorator,
 - I added `transaction.commit()` at the end of `tearDown`, otherwise the
 cache table isn't actually deleted, because `django.test.TestCase` is
 transactional.

-- 
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] #17268: r17119 broke the cache tests under PostgreSQL on the CI server

2011-11-20 Thread Django

#17268: r17119 broke the cache tests under PostgreSQL on the CI server
---+---
   Reporter:  aaugustin|  Owner:  aaugustin
   Type:  Bug  | Status:  new
  Component:  Core (Cache system)  |Version:
   Severity:  Release blocker  |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
 `test_add` and `test_cache_versioning_add` fail, apparently because of an
 improper rollback.

 Unfortunately, I can't reproduce this problem locally (OS X Lion,
 PostgreSQL 9.0 from MacPorts).

-- 
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] r17127 - django/trunk/django/views/generic

2011-11-20 Thread noreply

Author: aaugustin
Date: 2011-11-20 07:34:08 -0800 (Sun, 20 Nov 2011)
New Revision: 17127

Modified:
   django/trunk/django/views/generic/date_based.py
   django/trunk/django/views/generic/dates.py
Log:
Upgraded the date based generic views to avoid warnings when time zone support 
is enabled.



Modified: django/trunk/django/views/generic/date_based.py
===
--- django/trunk/django/views/generic/date_based.py 2011-11-20 15:29:39 UTC 
(rev 17126)
+++ django/trunk/django/views/generic/date_based.py 2011-11-20 15:34:08 UTC 
(rev 17127)
@@ -6,6 +6,7 @@
 from django.core.xheaders import populate_xheaders
 from django.db.models.fields import DateTimeField
 from django.http import Http404, HttpResponse
+from django.utils import timezone
 
 import warnings
 warnings.warn(
@@ -31,7 +32,7 @@
 if extra_context is None: extra_context = {}
 model = queryset.model
 if not allow_future:
-queryset = queryset.filter(**{'%s__lte' % date_field: 
datetime.datetime.now()})
+queryset = queryset.filter(**{'%s__lte' % date_field: timezone.now()})
 date_list = queryset.dates(date_field, 'year')[::-1]
 if not date_list and not allow_empty:
 raise Http404("No %s available" % model._meta.verbose_name)
@@ -74,7 +75,7 @@
 """
 if extra_context is None: extra_context = {}
 model = queryset.model
-now = datetime.datetime.now()
+now = timezone.now()
 
 lookup_kwargs = {'%s__year' % date_field: year}
 
@@ -131,7 +132,7 @@
 raise Http404
 
 model = queryset.model
-now = datetime.datetime.now()
+now = timezone.now()
 
 # Calculate first and last day of month, for use in a date-range lookup.
 first_day = date.replace(day=1)
@@ -205,7 +206,7 @@
 raise Http404
 
 model = queryset.model
-now = datetime.datetime.now()
+now = timezone.now()
 
 # Calculate first and last day of week, for use in a date-range lookup.
 first_day = date
@@ -263,7 +264,7 @@
 raise Http404
 
 model = queryset.model
-now = datetime.datetime.now()
+now = timezone.now()
 
 if isinstance(model._meta.get_field(date_field), DateTimeField):
 lookup_kwargs = {'%s__range' % date_field: 
(datetime.datetime.combine(date, datetime.time.min), 
datetime.datetime.combine(date, datetime.time.max))}
@@ -335,7 +336,7 @@
 raise Http404
 
 model = queryset.model
-now = datetime.datetime.now()
+now = timezone.now()
 
 if isinstance(model._meta.get_field(date_field), DateTimeField):
 lookup_kwargs = {'%s__range' % date_field: 
(datetime.datetime.combine(date, datetime.time.min), 
datetime.datetime.combine(date, datetime.time.max))}

Modified: django/trunk/django/views/generic/dates.py
===
--- django/trunk/django/views/generic/dates.py  2011-11-20 15:29:39 UTC (rev 
17126)
+++ django/trunk/django/views/generic/dates.py  2011-11-20 15:34:08 UTC (rev 
17127)
@@ -4,6 +4,7 @@
 from django.http import Http404
 from django.utils.encoding import force_unicode
 from django.utils.translation import ugettext as _
+from django.utils import timezone
 from django.views.generic.base import View
 from django.views.generic.detail import BaseDetailView, 
SingleObjectTemplateResponseMixin
 from django.views.generic.list import MultipleObjectMixin, 
MultipleObjectTemplateResponseMixin
@@ -191,7 +192,7 @@
 allow_empty = self.get_allow_empty()
 
 if not allow_future:
-qs = qs.filter(**{'%s__lte' % date_field: datetime.datetime.now()})
+qs = qs.filter(**{'%s__lte' % date_field: timezone.now()})
 
 if not allow_empty and not qs:
 raise Http404(_(u"No %(verbose_name_plural)s available") % {

-- 
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] #17252: Multi-sort in admin does not respect initial admin_order_field

2011-11-20 Thread Django

Comment (by sebastian):

One final thought regarding your [comment:4 comment]:
> However, I'm not entirely happy with the fix, in particular with the
fact that it makes the `ModelAdmin.ordering` option non explicit. For
example (based on your tests), to sort by a method called `some_order()`,
you have to set `ordering` to `('order',)`.

My patch doesn't change this, I'm simply using the current specification.
Having to set `ordering` explicitly to match the actual model field in
question is and was current behavior with and without my patch. In fact,
the docs for `contrib.admin` explicitly say:

From

https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.ordering:
> `ModelAdmin.ordering`: Set `ordering` to specify how lists of objects
should be ordered in the Django admin views. This should be a list or
tuple in the same format as a model's `ordering` parameter.

From

https://docs.djangoproject.com/en/dev/ref/models/options/#django.db.models.Options.ordering:
> `Options.ordering`: The default ordering for the object, for use when
obtaining lists of objects: (…) This is a tuple or list of strings. Each
string is a field name (…)

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

2011-11-20 Thread 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|
-+-

Comment (by aaugustin):

 In [17126]:
 {{{
 #!CommitTicketReference repository="" revision="17126"
 Ensured that the warning added at r17117 also applies to queryset filter
 arguments. Refs #17263.
 }}}

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

2011-11-20 Thread noreply

Author: aaugustin
Date: 2011-11-20 07:29:39 -0800 (Sun, 20 Nov 2011)
New Revision: 17126

Modified:
   django/trunk/tests/modeltests/timezones/tests.py
Log:
Ensured that the warning added at r17117 also applies to queryset filter 
arguments. Refs #17263.


Modified: django/trunk/tests/modeltests/timezones/tests.py
===
--- django/trunk/tests/modeltests/timezones/tests.py2011-11-20 11:12:37 UTC 
(rev 17125)
+++ django/trunk/tests/modeltests/timezones/tests.py2011-11-20 15:29:39 UTC 
(rev 17126)
@@ -242,6 +242,7 @@
 def test_naive_datetime(self):
 dt = datetime.datetime(2011, 9, 1, 13, 20, 30)
 with warnings.catch_warnings(record=True) as recorded:
+warnings.simplefilter('always')
 Event.objects.create(dt=dt)
 self.assertEqual(len(recorded), 1)
 msg = str(recorded[0].message)
@@ -255,6 +256,7 @@
 def test_naive_datetime_with_microsecond(self):
 dt = datetime.datetime(2011, 9, 1, 13, 20, 30, 405060)
 with warnings.catch_warnings(record=True) as recorded:
+warnings.simplefilter('always')
 Event.objects.create(dt=dt)
 self.assertEqual(len(recorded), 1)
 msg = str(recorded[0].message)
@@ -268,6 +270,7 @@
 def test_naive_datetime_with_microsecond_unsupported(self):
 dt = datetime.datetime(2011, 9, 1, 13, 20, 30, 405060)
 with warnings.catch_warnings(record=True) as recorded:
+warnings.simplefilter('always')
 Event.objects.create(dt=dt)
 self.assertEqual(len(recorded), 1)
 msg = str(recorded[0].message)
@@ -344,6 +347,22 @@
 self.assertEqual(Event.objects.filter(dt__in=(prev, dt, 
next)).count(), 1)
 self.assertEqual(Event.objects.filter(dt__range=(prev, next)).count(), 
1)
 
+@skipIf(sys.version_info < (2, 6), "this test requires Python >= 2.6")
+def test_query_filter_with_naive_datetime(self):
+dt = datetime.datetime(2011, 9, 1, 12, 20, 30, tzinfo=EAT)
+Event.objects.create(dt=dt)
+dt = dt.replace(tzinfo=None)
+with warnings.catch_warnings(record=True) as recorded:
+warnings.simplefilter('always')
+# naive datetimes are interpreted in local time
+self.assertEqual(Event.objects.filter(dt__exact=dt).count(), 1)
+self.assertEqual(Event.objects.filter(dt__lte=dt).count(), 1)
+self.assertEqual(Event.objects.filter(dt__gt=dt).count(), 0)
+self.assertEqual(len(recorded), 3)
+for warning in recorded:
+msg = str(warning.message)
+self.assertTrue(msg.startswith("DateTimeField received a naive 
datetime"))
+
 def test_query_date_related_filters(self):
 # These two dates fall in the same day in EAT, but in different days,
 # years and months in UTC, and aggregation is performed in UTC when

-- 
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] #17252: Multi-sort in admin does not respect initial admin_order_field

2011-11-20 Thread Django

#17252: Multi-sort in admin does not respect initial admin_order_field
-+-
 Reporter:  sebastian|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  multi-sort, admin,   | Triage Stage:  Accepted
  ordering   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  1
Easy pickings:  1|
-+-

Comment (by sebastian):

 Sure, making `ordering` more explicit would be nice but IMHO that's
 outside the scope of this ticket. Here, I'm only concerned with the
 regression introduced by the multi-sort addition to the admin which causes
 the initial sort indicator icons to not show up under certain
 circumstances, i.e. whenever something is sorted with `admin_order_field`.

 This bug is not a functional issue per se, but hiding those icons when the
 admin change list is actually sorted (which it is) is kind of misleading
 to the user.

 Regarding the proposition of making `ordering` more explicit, I suggest
 opening a new ticket for that and keeping this one for the regression at
 hand. Some questions arise, however, how far this more explicit `ordering`
 should reach: should method names also be allowed in models, ie. not only
 model admins? So would this be allowed:

 {{{#!python
 class MyModel(Model):
 foo = models.CharField()

 def bar(self):
 return self.foo
 bar.admin_order_field = 'foo'

 class Meta:
 ordering = ('bar',)  # <-- Should we be able to order by methods
 in the model, too?
  # If not, the currently analogous
 behavior of (Model|ModelAdmin).ordering is lost.
 }}}

 You see, I think this needs some more thought which cannot (or rather
 should not, IMHO) be covered in this purely regression-related ticket.

 What do you suggest?

-- 
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] #16822: HTTPRequest::raw_post_data broken for tests

2011-11-20 Thread Django

#16822: HTTPRequest::raw_post_data broken for tests
---+
 Reporter:  Whitney|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by jaylett):

 It doesn't resolve the original problem, but it allows test writers to do
 something sane rather than bomb out. Admittedly, without a precise test
 case for the original report I may be misunderstanding what Whitney's
 problem was…

-- 
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] #12073: AdminDateWidget and AdminTimeWidget not passing though additional attrs

2011-11-20 Thread Django

#12073: AdminDateWidget and AdminTimeWidget not passing though additional attrs
-+-
 Reporter:  elliss   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  widgets date time| Triage Stage:  Accepted
  calendar   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by julien):

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


Comment:

 In [17125]:
 {{{
 #!CommitTicketReference repository="" revision="17125"
 Fixed #12073 -- Made `AdminDateWidget` and `AdminTimeWidget` consider
 user-supplied `attrs`. Thanks to elliss for the report and to koenb for
 the patch.
 }}}

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

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

[Changeset] r17125 - in django/trunk: django/contrib/admin tests/regressiontests/admin_widgets

2011-11-20 Thread noreply

Author: julien
Date: 2011-11-20 03:12:37 -0800 (Sun, 20 Nov 2011)
New Revision: 17125

Modified:
   django/trunk/django/contrib/admin/widgets.py
   django/trunk/tests/regressiontests/admin_widgets/tests.py
Log:
Fixed #12073 -- Made `AdminDateWidget` and `AdminTimeWidget` consider 
user-supplied `attrs`. Thanks to elliss for the report and to koenb for the 
patch.

Modified: django/trunk/django/contrib/admin/widgets.py
===
--- django/trunk/django/contrib/admin/widgets.py2011-11-20 11:04:37 UTC 
(rev 17124)
+++ django/trunk/django/contrib/admin/widgets.py2011-11-20 11:12:37 UTC 
(rev 17125)
@@ -53,8 +53,11 @@
 js = ["calendar.js", "admin/DateTimeShortcuts.js"]
 return forms.Media(js=[static("admin/js/%s" % path) for path in js])
 
-def __init__(self, attrs={}, format=None):
-super(AdminDateWidget, self).__init__(attrs={'class': 'vDateField', 
'size': '10'}, format=format)
+def __init__(self, attrs=None, format=None):
+final_attrs = {'class': 'vDateField', 'size': '10'}
+if attrs is not None:
+final_attrs.update(attrs)
+super(AdminDateWidget, self).__init__(attrs=final_attrs, format=format)
 
 class AdminTimeWidget(forms.TimeInput):
 
@@ -63,8 +66,11 @@
 js = ["calendar.js", "admin/DateTimeShortcuts.js"]
 return forms.Media(js=[static("admin/js/%s" % path) for path in js])
 
-def __init__(self, attrs={}, format=None):
-super(AdminTimeWidget, self).__init__(attrs={'class': 'vTimeField', 
'size': '8'}, format=format)
+def __init__(self, attrs=None, format=None):
+final_attrs = {'class': 'vTimeField', 'size': '8'}
+if attrs is not None:
+final_attrs.update(attrs)
+super(AdminTimeWidget, self).__init__(attrs=final_attrs, format=format)
 
 class AdminSplitDateTime(forms.SplitDateTimeWidget):
 """

Modified: django/trunk/tests/regressiontests/admin_widgets/tests.py
===
--- django/trunk/tests/regressiontests/admin_widgets/tests.py   2011-11-20 
11:04:37 UTC (rev 17124)
+++ django/trunk/tests/regressiontests/admin_widgets/tests.py   2011-11-20 
11:12:37 UTC (rev 17125)
@@ -205,7 +205,42 @@
 '\naddEvent(window, "load", function(e) 
{SelectFilter.init("id_test", "test", 1, "%(ADMIN_MEDIA_PREFIX)s"); 
});\n' % admin_media_prefix()
 )
 
+class AdminDateWidgetTest(DjangoTestCase):
+def test_attrs(self):
+"""
+Ensure that user-supplied attrs are used.
+Refs #12073.
+"""
+w = widgets.AdminDateWidget()
+self.assertEqual(
+conditional_escape(w.render('test', datetime(2007, 12, 1, 9, 30))),
+'',
+)
+# pass attrs to widget
+w = widgets.AdminDateWidget(attrs={'size': 20, 'class': 'myDateField'})
+self.assertEqual(
+conditional_escape(w.render('test', datetime(2007, 12, 1, 9, 30))),
+'',
+)
 
+class AdminTimeWidgetTest(DjangoTestCase):
+def test_attrs(self):
+"""
+Ensure that user-supplied attrs are used.
+Refs #12073.
+"""
+w = widgets.AdminTimeWidget()
+self.assertEqual(
+conditional_escape(w.render('test', datetime(2007, 12, 1, 9, 30))),
+'',
+)
+# pass attrs to widget
+w = widgets.AdminTimeWidget(attrs={'size': 20, 'class': 'myTimeField'})
+self.assertEqual(
+conditional_escape(w.render('test', datetime(2007, 12, 1, 9, 30))),
+'',
+)
+
 class AdminSplitDateTimeWidgetTest(DjangoTestCase):
 def test_render(self):
 w = widgets.AdminSplitDateTime()

-- 
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] r17124 - django/trunk/django/core/management/commands

2011-11-20 Thread noreply

Author: aaugustin
Date: 2011-11-20 03:04:37 -0800 (Sun, 20 Nov 2011)
New Revision: 17124

Modified:
   django/trunk/django/core/management/commands/cleanup.py
Log:
Upgraded manage.py cleanup to be compatible with time zone support. See also 
r17121.



Modified: django/trunk/django/core/management/commands/cleanup.py
===
--- django/trunk/django/core/management/commands/cleanup.py 2011-11-20 
10:58:20 UTC (rev 17123)
+++ django/trunk/django/core/management/commands/cleanup.py 2011-11-20 
11:04:37 UTC (rev 17124)
@@ -1,5 +1,5 @@
-import datetime
 from django.core.management.base import NoArgsCommand
+from django.utils import timezone
 
 class Command(NoArgsCommand):
 help = "Can be run as a cronjob or directly to clean out old data from the 
database (only expired sessions at the moment)."
@@ -7,5 +7,5 @@
 def handle_noargs(self, **options):
 from django.db import transaction
 from django.contrib.sessions.models import Session
-
Session.objects.filter(expire_date__lt=datetime.datetime.now()).delete()
+Session.objects.filter(expire_date__lt=timezone.now()).delete()
 transaction.commit_unless_managed()

-- 
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] r17123 - django/trunk/django/contrib/comments

2011-11-20 Thread noreply

Author: aaugustin
Date: 2011-11-20 02:58:20 -0800 (Sun, 20 Nov 2011)
New Revision: 17123

Modified:
   django/trunk/django/contrib/comments/forms.py
   django/trunk/django/contrib/comments/models.py
   django/trunk/django/contrib/comments/moderation.py
Log:
Upgraded django.contrib.comments to be compatible with time zone support.



Modified: django/trunk/django/contrib/comments/forms.py
===
--- django/trunk/django/contrib/comments/forms.py   2011-11-20 10:50:18 UTC 
(rev 17122)
+++ django/trunk/django/contrib/comments/forms.py   2011-11-20 10:58:20 UTC 
(rev 17123)
@@ -1,4 +1,3 @@
-import datetime
 import time
 from django import forms
 from django.forms.util import ErrorDict
@@ -8,6 +7,7 @@
 from django.utils.crypto import salted_hmac, constant_time_compare
 from django.utils.encoding import force_unicode
 from django.utils.text import get_text_list
+from django.utils import timezone
 from django.utils.translation import ungettext, ugettext_lazy as _
 
 COMMENT_MAX_LENGTH = getattr(settings,'COMMENT_MAX_LENGTH', 3000)
@@ -138,7 +138,7 @@
 user_email   = self.cleaned_data["email"],
 user_url = self.cleaned_data["url"],
 comment  = self.cleaned_data["comment"],
-submit_date  = datetime.datetime.now(),
+submit_date  = timezone.now(),
 site_id  = settings.SITE_ID,
 is_public= True,
 is_removed   = False,

Modified: django/trunk/django/contrib/comments/models.py
===
--- django/trunk/django/contrib/comments/models.py  2011-11-20 10:50:18 UTC 
(rev 17122)
+++ django/trunk/django/contrib/comments/models.py  2011-11-20 10:58:20 UTC 
(rev 17123)
@@ -1,4 +1,3 @@
-import datetime
 from django.contrib.auth.models import User
 from django.contrib.comments.managers import CommentManager
 from django.contrib.contenttypes import generic
@@ -7,6 +6,7 @@
 from django.db import models
 from django.core import urlresolvers
 from django.utils.translation import ugettext_lazy as _
+from django.utils import timezone
 from django.conf import settings
 
 COMMENT_MAX_LENGTH = getattr(settings,'COMMENT_MAX_LENGTH',3000)
@@ -81,7 +81,7 @@
 
 def save(self, *args, **kwargs):
 if self.submit_date is None:
-self.submit_date = datetime.datetime.now()
+self.submit_date = timezone.now()
 super(Comment, self).save(*args, **kwargs)
 
 def _get_userinfo(self):
@@ -187,5 +187,5 @@
 
 def save(self, *args, **kwargs):
 if self.flag_date is None:
-self.flag_date = datetime.datetime.now()
+self.flag_date = timezone.now()
 super(CommentFlag, self).save(*args, **kwargs)

Modified: django/trunk/django/contrib/comments/moderation.py
===
--- django/trunk/django/contrib/comments/moderation.py  2011-11-20 10:50:18 UTC 
(rev 17122)
+++ django/trunk/django/contrib/comments/moderation.py  2011-11-20 10:58:20 UTC 
(rev 17123)
@@ -63,6 +63,7 @@
 from django.template import Context, loader
 from django.contrib import comments
 from django.contrib.sites.models import Site
+from django.utils import timezone
 
 class AlreadyModerated(Exception):
 """
@@ -207,7 +208,7 @@
 return False
 if self.auto_close_field and self.close_after is not None:
 close_after_date = getattr(content_object, self.auto_close_field)
-if close_after_date is not None and 
self._get_delta(datetime.datetime.now(), close_after_date).days >= 
self.close_after:
+if close_after_date is not None and 
self._get_delta(timezone.now(), close_after_date).days >= self.close_after:
 return False
 return True
 
@@ -223,7 +224,7 @@
 """
 if self.auto_moderate_field and self.moderate_after is not None:
 moderate_after_date = getattr(content_object, 
self.auto_moderate_field)
-if moderate_after_date is not None and 
self._get_delta(datetime.datetime.now(), moderate_after_date).days >= 
self.moderate_after:
+if moderate_after_date is not None and 
self._get_delta(timezone.now(), moderate_after_date).days >= 
self.moderate_after:
 return True
 return False
 

-- 
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] r17122 - in django/trunk/django/contrib/auth: . tests

2011-11-20 Thread noreply

Author: aaugustin
Date: 2011-11-20 02:50:18 -0800 (Sun, 20 Nov 2011)
New Revision: 17122

Modified:
   django/trunk/django/contrib/auth/models.py
   django/trunk/django/contrib/auth/tests/remote_user.py
Log:
Upgraded django.contrib.auth to be compatible with time zone support.



Modified: django/trunk/django/contrib/auth/models.py
===
--- django/trunk/django/contrib/auth/models.py  2011-11-20 10:33:44 UTC (rev 
17121)
+++ django/trunk/django/contrib/auth/models.py  2011-11-20 10:50:18 UTC (rev 
17122)
@@ -1,4 +1,3 @@
-import datetime
 import urllib
 
 from django.core.exceptions import ImproperlyConfigured
@@ -7,6 +6,7 @@
 from django.db.models.manager import EmptyManager
 from django.utils.encoding import smart_str
 from django.utils.translation import ugettext_lazy as _
+from django.utils import timezone
 
 from django.contrib import auth
 from django.contrib.auth.signals import user_logged_in
@@ -21,7 +21,7 @@
 A signal receiver which updates the last_login date for
 the user logging in.
 """
-user.last_login = datetime.datetime.now()
+user.last_login = timezone.now()
 user.save()
 user_logged_in.connect(update_last_login)
 
@@ -91,7 +91,7 @@
 """
 Creates and saves a User with the given username, email and password.
 """
-now = datetime.datetime.now()
+now = timezone.now()
 
 # Normalize the address by lowercasing the domain part of the email
 # address.
@@ -181,8 +181,8 @@
 is_staff = models.BooleanField(_('staff status'), default=False, 
help_text=_("Designates whether the user can log into this admin site."))
 is_active = models.BooleanField(_('active'), default=True, 
help_text=_("Designates whether this user should be treated as active. Unselect 
this instead of deleting accounts."))
 is_superuser = models.BooleanField(_('superuser status'), default=False, 
help_text=_("Designates that this user has all permissions without explicitly 
assigning them."))
-last_login = models.DateTimeField(_('last login'), 
default=datetime.datetime.now)
-date_joined = models.DateTimeField(_('date joined'), 
default=datetime.datetime.now)
+last_login = models.DateTimeField(_('last login'), default=timezone.now)
+date_joined = models.DateTimeField(_('date joined'), default=timezone.now)
 groups = models.ManyToManyField(Group, verbose_name=_('groups'), 
blank=True,
 help_text=_("In addition to the permissions manually assigned, this 
user will also get all permissions granted to each group he/she is in."))
 user_permissions = models.ManyToManyField(Permission, verbose_name=_('user 
permissions'), blank=True)

Modified: django/trunk/django/contrib/auth/tests/remote_user.py
===
--- django/trunk/django/contrib/auth/tests/remote_user.py   2011-11-20 
10:33:44 UTC (rev 17121)
+++ django/trunk/django/contrib/auth/tests/remote_user.py   2011-11-20 
10:50:18 UTC (rev 17122)
@@ -4,6 +4,7 @@
 from django.contrib.auth.backends import RemoteUserBackend
 from django.contrib.auth.models import User
 from django.test import TestCase
+from django.utils import timezone
 
 
 class RemoteUserTest(TestCase):
@@ -80,6 +81,8 @@
 user = User.objects.create(username='knownuser')
 # Set last_login to something so we can determine if it changes.
 default_login = datetime(2000, 1, 1)
+if settings.USE_TZ:
+default_login = default_login.replace(tzinfo=timezone.utc)
 user.last_login = default_login
 user.save()
 

-- 
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] #17252: Multi-sort in admin does not respect initial admin_order_field

2011-11-20 Thread Django

#17252: Multi-sort in admin does not respect initial admin_order_field
-+-
 Reporter:  sebastian|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  multi-sort, admin,   | Triage Stage:  Accepted
  ordering   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  1
Easy pickings:  1|
-+-
Changes (by julien):

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


Comment:

 Thanks for providing tests, this helps reproducing this issue quite
 clearly.

 However, I'm not entirely happy with the fix, in particular with the fact
 that it makes the `ModelAdmin.ordering` option non explicit. For example
 (based on your tests), to sort  by a method called `some_order()`, you
 have to set `ordering` to `('order',)`.

 `ModelAdmin.ordering` currently only accepts actual model fields. I think
 it should be modified to also accept any method/function as long as they
 define a `admin_order_field` pointing to an actual model field. That way
 one could explicitly do:

 {{{#!python

 class MyModel(Model):
 foo = models.CharField()

 class MyModelAdmin(ModelAdmin):

 def bar(self, obj):
 return obj.foo
 bar.admin_order_field = 'foo'

 list_display = ('bar',)
 ordering = ('bar',)  # <-- Can order by method 'bar'
 }}}

-- 
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] r17121 - in django/trunk/django/contrib/sessions: . backends

2011-11-20 Thread noreply

Author: aaugustin
Date: 2011-11-20 02:33:44 -0800 (Sun, 20 Nov 2011)
New Revision: 17121

Modified:
   django/trunk/django/contrib/sessions/backends/base.py
   django/trunk/django/contrib/sessions/backends/db.py
   django/trunk/django/contrib/sessions/tests.py
Log:
Upgraded django.contrib.sessions to be compatible with time zone support.


Modified: django/trunk/django/contrib/sessions/backends/base.py
===
--- django/trunk/django/contrib/sessions/backends/base.py   2011-11-20 
10:31:22 UTC (rev 17120)
+++ django/trunk/django/contrib/sessions/backends/base.py   2011-11-20 
10:33:44 UTC (rev 17121)
@@ -12,6 +12,7 @@
 from django.conf import settings
 from django.core.exceptions import SuspiciousOperation
 from django.utils.crypto import constant_time_compare, salted_hmac
+from django.utils import timezone
 
 # Use the system (hardware-based) random number generator if it exists.
 if hasattr(random, 'SystemRandom'):
@@ -188,7 +189,7 @@
 return settings.SESSION_COOKIE_AGE
 if not isinstance(expiry, datetime):
 return expiry
-delta = expiry - datetime.now()
+delta = expiry - timezone.now()
 return delta.days * 86400 + delta.seconds
 
 def get_expiry_date(self):
@@ -198,7 +199,7 @@
 return expiry
 if not expiry:   # Checks both None and 0 cases
 expiry = settings.SESSION_COOKIE_AGE
-return datetime.now() + timedelta(seconds=expiry)
+return timezone.now() + timedelta(seconds=expiry)
 
 def set_expiry(self, value):
 """
@@ -223,7 +224,7 @@
 pass
 return
 if isinstance(value, timedelta):
-value = datetime.now() + value
+value = timezone.now() + value
 self['_session_expiry'] = value
 
 def get_expire_at_browser_close(self):

Modified: django/trunk/django/contrib/sessions/backends/db.py
===
--- django/trunk/django/contrib/sessions/backends/db.py 2011-11-20 10:31:22 UTC 
(rev 17120)
+++ django/trunk/django/contrib/sessions/backends/db.py 2011-11-20 10:33:44 UTC 
(rev 17121)
@@ -1,8 +1,8 @@
-import datetime
 from django.contrib.sessions.backends.base import SessionBase, CreateError
 from django.core.exceptions import SuspiciousOperation
 from django.db import IntegrityError, transaction, router
 from django.utils.encoding import force_unicode
+from django.utils import timezone
 
 
 class SessionStore(SessionBase):
@@ -16,7 +16,7 @@
 try:
 s = Session.objects.get(
 session_key = self.session_key,
-expire_date__gt=datetime.datetime.now()
+expire_date__gt=timezone.now()
 )
 return self.decode(force_unicode(s.session_data))
 except (Session.DoesNotExist, SuspiciousOperation):

Modified: django/trunk/django/contrib/sessions/tests.py
===
--- django/trunk/django/contrib/sessions/tests.py   2011-11-20 10:31:22 UTC 
(rev 17120)
+++ django/trunk/django/contrib/sessions/tests.py   2011-11-20 10:33:44 UTC 
(rev 17121)
@@ -16,6 +16,7 @@
 from django.http import HttpResponse
 from django.test import TestCase, RequestFactory
 from django.test.utils import override_settings
+from django.utils import timezone
 from django.utils import unittest
 
 
@@ -187,7 +188,7 @@
 def test_custom_expiry_seconds(self):
 # Using seconds
 self.session.set_expiry(10)
-delta = self.session.get_expiry_date() - datetime.now()
+delta = self.session.get_expiry_date() - timezone.now()
 self.assertTrue(delta.seconds in (9, 10))
 
 age = self.session.get_expiry_age()
@@ -196,7 +197,7 @@
 def test_custom_expiry_timedelta(self):
 # Using timedelta
 self.session.set_expiry(timedelta(seconds=10))
-delta = self.session.get_expiry_date() - datetime.now()
+delta = self.session.get_expiry_date() - timezone.now()
 self.assertTrue(delta.seconds in (9, 10))
 
 age = self.session.get_expiry_age()
@@ -204,8 +205,8 @@
 
 def test_custom_expiry_datetime(self):
 # Using fixed datetime
-self.session.set_expiry(datetime.now() + timedelta(seconds=10))
-delta = self.session.get_expiry_date() - datetime.now()
+self.session.set_expiry(timezone.now() + timedelta(seconds=10))
+delta = self.session.get_expiry_date() - timezone.now()
 self.assertTrue(delta.seconds in (9, 10))
 
 age = self.session.get_expiry_age()
@@ -279,10 +280,17 @@
 self.assertEqual(self.session['y'], 2)
 
 
+DatabaseSessionWithTimeZoneTests = 
override_settings(USE_TZ=True)(DatabaseSessionTests)
+
+
 class CacheDBSessionTests(SessionTestsMixin, TestCase):
 
 backend = CacheDBSession
 
+
+CacheDBSessionWithTimeZoneTests =

[Changeset] r17120 - django/trunk/docs/ref

2011-11-20 Thread noreply

Author: aaugustin
Date: 2011-11-20 02:31:22 -0800 (Sun, 20 Nov 2011)
New Revision: 17120

Modified:
   django/trunk/docs/ref/databases.txt
Log:
Fixed #17267 -- Clarified the description of MyISAM's lack of support for 
foreign keys.


Modified: django/trunk/docs/ref/databases.txt
===
--- django/trunk/docs/ref/databases.txt 2011-11-20 10:17:12 UTC (rev 17119)
+++ django/trunk/docs/ref/databases.txt 2011-11-20 10:31:22 UTC (rev 17120)
@@ -135,9 +135,10 @@
 MySQL has several `storage engines`_ (previously called table types). You can
 change the default storage engine in the server configuration.
 
-The default engine is MyISAM_ [#]_. The main drawback of MyISAM is that it
-doesn't currently support transactions or foreign keys. On the plus side, it's
-currently the only engine that supports full-text indexing and searching.
+The default engine is MyISAM_ [#]_. The main drawbacks of MyISAM are that it
+doesn't currently support transactions or enforce foreign keys constraints. On
+the plus side, it's currently the only engine that supports full-text indexing
+and searching.
 
 The InnoDB_ engine is fully transactional and supports foreign key references
 and is probably the best choice at this point in time.

-- 
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] #17267: MySQL Storage Engines: MyISAM doesn't support Foreign Keys

2011-11-20 Thread Django

#17267: MySQL Storage Engines: MyISAM doesn't support Foreign Keys
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.2
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  database, mysql, |  Needs documentation:  0
  'storage engine', myisam,  |  Patch needs improvement:  0
  'foreign key'  |UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by aaugustin):

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


Comment:

 In [17120]:
 {{{
 #!CommitTicketReference repository="" revision="17120"
 Fixed #17267 -- Clarified the description of MyISAM's lack of support for
 foreign keys.
 }}}

-- 
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] #17267: MySQL Storage Engines: MyISAM doesn't support Foreign Keys

2011-11-20 Thread Django

#17267: MySQL Storage Engines: MyISAM doesn't support Foreign Keys
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.2
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  database, mysql, |  Needs documentation:  0
  'storage engine', myisam,  |  Patch needs improvement:  0
  'foreign key'  |UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by aaugustin):

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


Comment:

 1. No, Django does rely on the database for foreign key checks — that's
 its job!
 2. Yes, the wording could be clarified.

-- 
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] #17267: MySQL Storage Engines: MyISAM doesn't support Foreign Keys

2011-11-20 Thread Django

#17267: MySQL Storage Engines: MyISAM doesn't support Foreign Keys
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.2
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  database, mysql, |  Unreviewed
  'storage engine', myisam,  |  Needs documentation:  0
  'foreign key'  |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Old description:

> I was really wondering what this is supposed to mean. How can a
> Relational Database not support foreign keys?
> So I had to go to to freenode#mysql to ask.
>
>  or to be more precise, myisam doesn't support Foreign Key
> _Constraints_
>  so I only have to check myself that the target of the FK is
> existant in the target table?
>  jay567: it means, although you can define a myisam table with a
> CONSTRAINT FOREIGN KEY (col1) REFERENCES othertable (foocol) ON DELETE
> CASCADE ... , myisam will ignore this and will not enforce FK constraint
>  jay567: yes, you will have to check that yourself
>  jay567: if you don't have a very good reason to use myisam, you
> should use innodb anyways :)
>
> so
> 1. This shouldn't be an issue with Django, because it does not rely on
> the database for the above check, right?
> 2. Could you please try to be more clear, so people like me don't need to
> wonder (see first two sentences)?

New description:

 I was really wondering what this is supposed to mean. How can a Relational
 Database not support foreign keys?
 So I had to go to to freenode#mysql to ask.

 {{{
  or to be more precise, myisam doesn't support Foreign Key
 _Constraints_
  so I only have to check myself that the target of the FK is
 existant in the target table?
  jay567: it means, although you can define a myisam table with a
 CONSTRAINT FOREIGN KEY (col1) REFERENCES othertable (foocol) ON DELETE
 CASCADE ... , myisam will ignore this and will not enforce FK constraint
  jay567: yes, you will have to check that yourself
  jay567: if you don't have a very good reason to use myisam, you
 should use innodb anyways :)
 }}}

 so
 1. This shouldn't be an issue with Django, because it does not rely on the
 database for the above check, right?
 2. Could you please try to be more clear, so people like me don't need to
 wonder (see first two sentences)?

--

-- 
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] #17267: MySQL Storage Engines: MyISAM doesn't support Foreign Keys

2011-11-20 Thread Django

#17267: MySQL Storage Engines: MyISAM doesn't support Foreign Keys
-+-
 Reporter:  anonymous|  Owner:  nobody
 Type:   | Status:  new
  Cleanup/optimization   |Version:  1.2
Component:  Documentation|   Keywords:  database, mysql,
 Severity:  Normal   |  'storage engine', myisam, 'foreign
 Triage Stage:  Unreviewed   |  key'
Easy pickings:  0|  Has patch:  0
 |  UI/UX:  0
-+-
 I was really wondering what this is supposed to mean. How can a Relational
 Database not support foreign keys?
 So I had to go to to freenode#mysql to ask.

  or to be more precise, myisam doesn't support Foreign Key
 _Constraints_
  so I only have to check myself that the target of the FK is
 existant in the target table?
  jay567: it means, although you can define a myisam table with a
 CONSTRAINT FOREIGN KEY (col1) REFERENCES othertable (foocol) ON DELETE
 CASCADE ... , myisam will ignore this and will not enforce FK constraint
  jay567: yes, you will have to check that yourself
  jay567: if you don't have a very good reason to use myisam, you
 should use innodb anyways :)

 so
 1. This shouldn't be an issue with Django, because it does not rely on the
 database for the above check, right?
 2. Could you please try to be more clear, so people like me don't need to
 wonder (see first two sentences)?

-- 
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] r17119 - in django/trunk: django/core/cache/backends tests/regressiontests/cache

2011-11-20 Thread noreply

Author: aaugustin
Date: 2011-11-20 02:17:12 -0800 (Sun, 20 Nov 2011)
New Revision: 17119

Modified:
   django/trunk/django/core/cache/backends/db.py
   django/trunk/tests/regressiontests/cache/models.py
   django/trunk/tests/regressiontests/cache/tests.py
Log:
Made the database cache backend, which bypasses the ORM, compatible with time 
zone support.



Modified: django/trunk/django/core/cache/backends/db.py
===
--- django/trunk/django/core/cache/backends/db.py   2011-11-20 07:40:19 UTC 
(rev 17118)
+++ django/trunk/django/core/cache/backends/db.py   2011-11-20 10:17:12 UTC 
(rev 17119)
@@ -8,8 +8,10 @@
 except ImportError:
 import pickle
 
+from django.conf import settings
 from django.core.cache.backends.base import BaseCache
 from django.db import connections, router, transaction, DatabaseError
+from django.utils import timezone
 
 
 class Options(object):
@@ -38,6 +40,17 @@
 self.cache_model_class = CacheEntry
 
 class DatabaseCache(BaseDatabaseCache):
+
+# This class uses cursors provided by the database connection. This means
+# it reads expiration values as aware or naive datetimes depending on the
+# value of USE_TZ. They must be compared to aware or naive representations
+# of "now" respectively.
+
+# But it bypasses the ORM for write operations. As a consequence, aware
+# datetimes aren't made naive for databases that don't support time zones.
+# We work around this problem by always using naive datetimes when writing
+# expiration values, in UTC when USE_TZ = True and in local time otherwise.
+
 def get(self, key, default=None, version=None):
 key = self.make_key(key, version=version)
 self.validate_key(key)
@@ -45,15 +58,17 @@
 table = connections[db].ops.quote_name(self._table)
 cursor = connections[db].cursor()
 
-cursor.execute("SELECT cache_key, value, expires FROM %s WHERE 
cache_key = %%s" % table, [key])
+cursor.execute("SELECT cache_key, value, expires FROM %s "
+   "WHERE cache_key = %%s" % table, [key])
 row = cursor.fetchone()
 if row is None:
 return default
-now = datetime.now()
+now = timezone.now()
 if row[2] < now:
 db = router.db_for_write(self.cache_model_class)
 cursor = connections[db].cursor()
-cursor.execute("DELETE FROM %s WHERE cache_key = %%s" % table, 
[key])
+cursor.execute("DELETE FROM %s "
+   "WHERE cache_key = %%s" % table, [key])
 transaction.commit_unless_managed(using=db)
 return default
 value = connections[db].ops.process_clob(row[1])
@@ -78,20 +93,28 @@
 
 cursor.execute("SELECT COUNT(*) FROM %s" % table)
 num = cursor.fetchone()[0]
-now = datetime.now().replace(microsecond=0)
-exp = datetime.fromtimestamp(time.time() + 
timeout).replace(microsecond=0)
+now = timezone.now()
+now = now.replace(microsecond=0)
+if settings.USE_TZ:
+exp = datetime.utcfromtimestamp(time.time() + timeout)
+else:
+exp = datetime.fromtimestamp(time.time() + timeout)
+exp = exp.replace(microsecond=0)
 if num > self._max_entries:
 self._cull(db, cursor, now)
 encoded = base64.encodestring(pickle.dumps(value, 2)).strip()
-cursor.execute("SELECT cache_key, expires FROM %s WHERE cache_key = 
%%s" % table, [key])
+cursor.execute("SELECT cache_key, expires FROM %s "
+   "WHERE cache_key = %%s" % table, [key])
 try:
 result = cursor.fetchone()
 if result and (mode == 'set' or
 (mode == 'add' and result[1] < now)):
-cursor.execute("UPDATE %s SET value = %%s, expires = %%s WHERE 
cache_key = %%s" % table,
+cursor.execute("UPDATE %s SET value = %%s, expires = %%s "
+   "WHERE cache_key = %%s" % table,
[encoded, 
connections[db].ops.value_to_db_datetime(exp), key])
 else:
-cursor.execute("INSERT INTO %s (cache_key, value, expires) 
VALUES (%%s, %%s, %%s)" % table,
+cursor.execute("INSERT INTO %s (cache_key, value, expires) "
+   "VALUES (%%s, %%s, %%s)" % table,
[key, encoded, 
connections[db].ops.value_to_db_datetime(exp)])
 except DatabaseError:
 # To be threadsafe, updates/inserts are allowed to fail silently
@@ -120,8 +143,13 @@
 table = connections[db].ops.quote_name(self._table)
 cursor = connections[db].cursor()
 
-now = datetime.now().replace(microsecond=0)
-cursor.execute("SELECT cache_key FROM %s WHERE cache_key = %%s and 
expires > %%s" % table,
+if settings.USE_TZ:
+now =

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

2011-11-20 Thread 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 ticket about get_parameter_status is #17266. This ticket will need to
 be resolved before working on that ticket.

-- 
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] #17266: psycopg2 backend should use get_parameter_status to check if SET TIME ZONE is needed

2011-11-20 Thread Django

#17266: psycopg2 backend should use get_parameter_status to check if SET TIME 
ZONE
is needed
--+
 Reporter:  akaariai  |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 In ticket #17062 Aymeric Augustin suggested the idea for using
 get_parameter_status to check if the database default time zone is already
 correct. If it is, we can skip the SET TIME ZONE and associated isolation
 level handling for every new connection. Ticket #17062 has more details,
 but I will copy-paste the most relevant parts here. If this is not done,
 for every new connection we need to do these queries:
 {{{
 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...
 }}}

 If we use get_parameter_status, we can get it down to this:
 {{{
 27163: LOG:  connection authorized: user=akaj database=testdb1
 27163: LOG:  statement: SHOW default_transaction_isolation
 27163: LOG:  statement: BEGIN
 27163: LOG:  statement: first real query
 }}}

 The get_parameter_status was added in psycopg2 version 2.0.12
 
[http://initd.org/psycopg/docs/connection.html#connection.get_parameter_status].
 I can't find a mention if we need to support versions prior to this. If we
 need to support versions prior to 2.0.12, we can just add a check for the
 psycopg2 version in use and not use get_parameter_status if the version
 doesn't support it.

 I will wait until ticket #17062 gets fixed before working on 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] #17032: Tests for contrib.auth fail if login signals use templates

2011-11-20 Thread 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
-+-

Comment (by julien):

 For the record, I think this is just a symptom of a deeper problem, i.e.
 that Django doesn't provide a clean environment for unit tests to be run
 in. Other examples of such symptomatic issues are: #17194, #13394, #16366,
 #10976, #8404, #16413, and many more. Whatever we do to fix those symptoms
 we will always keep finding more and more of them — this just has no end
 as it's impossible to predict all the combinations of settings people
 might use in the wild with their projects. Patching those tests with
 little fixes does make them more isolated, but it also does make the tests
 harder to read as it increases the amount of boilerplate code inside the
 tests, without doing anything really useful like increasing the code
 coverage or fixing actual bugs in the tested code.

 As stated earlier in this thread, I see no reason for running the Django
 contrib apps from one's project with '`manage.py test`' at all. Those
 tests are already run by the CI server, and running them from your project
 will add no value to you. They can only cause annoyances when they fail
 because of isolation problems. This is why I recommend to simply ignore
 those tests and not run them from your project.

 I contend that our energy would be better spent focusing on finding a more
 general solution to the root cause. I don't think much work has been done
 in that area yet. I know at least of #9156 addresses 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] #17062: Using postgres, if you rollback the first transaction on a connection, the effect of settings.TIME_ZONE is lost

2011-11-20 Thread 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):

 I figured it would be useful to post the work I did for the examples above
 into this ticket. I know this is not assigned to me, but as I have the
 code lying around it seems a bit silly not to post it here...

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

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

62 matches

Mail list logo