Re: [Django] #17520: write queries on related managers use the db_for_read database

[Django]

#17520: write queries on related managers use the db_for_read database
-+-
 Reporter:  tobias   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 Indeed, the test case looks valid and fails.

-- 
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] #10625: Ewkt regexp incorrectly escaped in GeoDjango admin javascript

[Django]

#10625: Ewkt regexp incorrectly escaped in GeoDjango admin javascript
-+---
 Reporter:  timlinux |Owner:  springmeyer
 Type:  Bug  |   Status:  reopened
Component:  GIS  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  regexp ewkt  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---

Comment (by aaugustin):

 I'm attaching the patch (1 char). I don't have time to test this now.

-- 
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] #10625: Ewkt regexp incorrectly escaped in GeoDjango admin javascript

[Django]

#10625: Ewkt regexp incorrectly escaped in GeoDjango admin javascript
-+---
 Reporter:  timlinux |Owner:  springmeyer
 Type:  Bug  |   Status:  reopened
Component:  GIS  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  regexp ewkt  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---
Changes (by aaugustin):

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


Comment:

 From code inspection, I'm convinced that the bug report is correct. All
 other !JavaScript regexps use double backslashes.

-- 
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] #17635: Missing ability to cast georaphy to geometry when using GeoDjango and PostgresSQL

[Django]

#17635: Missing ability to cast georaphy to geometry when using GeoDjango and
PostgresSQL
-+-
 Reporter:  corentin.chary@… |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Design decision needed


Old description:

> Looking at
> http://postgis.refractions.net/docs/ch08.html#PostGIS_TypeFunctionMatrix
> you will see that a lot of functions only work on geometric fields (ie:
> geography=False).
>
> That means something like Markers.objects.extent() won't work if the
> coordinate field of Marker have geography set to True because the
> underlying function (ST_Extent()) only work with geometric fields.
>
> A workaround (if you don't really care about precision) is to cast
> geography to geometry:
>
>SELECT ST_Extent(coordinates::geometry) FROM markers;
>
> That will perfectly work. However, you can't really do that with django.
> The best you can do seems to be:
>
>qs.extra(select={'extent':
> 'ST_Extent("coordinates"::geometry)'}).values('extent')
>
> But that's really far from perfect.
>
> Here are some propositions:
> - add a way to cast to geometry, that would allow to do:
> qs.extent(field_name=coordinates__geometry) (the trailing __geometry cast
> a GeometryField from geography to geometry)
> - another way to cast to geometry would be:
> qs.geometry('coordinates').extent()
> - automatically cast geography to geometry if a function only support
> geometry (hum...)

New description:

 Looking at
 http://postgis.refractions.net/docs/ch08.html#PostGIS_TypeFunctionMatrix
 you will see that a lot of functions only work on geometric fields (ie:
 geography=False).

 That means something like Markers.objects.extent() won't work if the
 coordinate field of Marker have geography set to True because the
 underlying function (ST_Extent()) only work with geometric fields.

 A workaround (if you don't really care about precision) is to cast
 geography to geometry:

SELECT ST_Extent(coordinates::geometry) FROM markers;

 That will perfectly work. However, you can't really do that with django.
 The best you can do seems to be:

qs.extra(select={'extent':
 'ST_Extent("coordinates"::geometry)'}).values('extent')

 But that's really far from perfect.

 Here are some propositions:
 - add a way to cast to geometry, that would allow to do:
 `qs.extent(field_name=coordinates__geometry)` (the trailing `__geometry`
 cast a GeometryField from geography to geometry)
 - another way to cast to geometry would be:
 `qs.geometry('coordinates').extent()`
 - automatically cast geography to geometry if a function only support
 geometry (hum...)

--

Comment:

 I've encountered the same problem (with `point_on_surface` and `envelope`)
 and I didn't even manage to resolve it with Django's public APIs.

 Here's what I ended up with:

 {{{
 class ZoneManager(gis_models.GeoManager):

 def point_on_surface_and_envelope(self):
 # Use a private API to adapt point_on_surface and envelope for a
 # geographic field. See
 django.contrib.gis.db.models.query.GeoQuerySet.
 return self.all()._spatial_attribute('point_on_surface', {
 'select_field' : GeomField(),
 'procedure_fmt': '%(geo_col)s::geometry',   # added
 '::geometry'
 })._spatial_attribute('envelope', {
 'select_field' : GeomField(),
 'procedure_fmt': '%(geo_col)s::geometry',   # added
 '::geometry'
 })
 }}}

 Maybe I should have started with geometry fields instead of geography
 fields, but I didn't expect to need these functions...

 -

 While I'm interested in a solution to this problem, I'm not convinced we
 should allow these kind of approximations.

 Marking as DDN for now, the GIS maintainer may have a stronger opinion on
 this matter.

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

Re: [Django] #17756: GeoDjango missing pyspatialite support

[Django]

#17756: GeoDjango missing pyspatialite support
-+
 Reporter:  danols   |Owner:  danols
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  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:  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] #17763: Problem with auth_permission name length

[Django]

#17763: Problem with auth_permission name length
--+
 Reporter:  stenius@… |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by aaugustin):

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


Comment:

 Django should check the length of the permission name before attempting to
 it.

 If it's too long, I see two possible solutions:

 1 - raise an error better error message, telling to use a shorter model
 name

 Indeed, even the simplest of views is hard to read with such long model
 names:

 {{{
 def my_view(request):
 questions =
 StudyPlanPracticeAssessmentTutorialQuestion.objects.filter(tutorial=...)
 }}}

 Python encourages concise and readable code, I'm fine with not supporting
 "app + model" names above 50 chars.

 2 - only raise a warning and automatically truncate the name to 50 chars

 But then there's still a problem when two models have the same prefix, for
 instance:
 * `StudyPlanPracticeAssessmentTutorialMultipleChoicesQuestionAnswer`
 *
 
`StudyPlanPracticeAssessmentTutorialMultipleChoicesQuestionAnswerEvaluationElement`

 Technically, we could write something like `if len(name) > 50: name =
 name[:46] + hash(name[46:])[:4]`, but that won't help end users
 manipulating permissions to distinguish the two permissions.

 I prefer solution 1.

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

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

Re: [Django] #17815: Turkish plural forms incorrect

[Django]

#17815: Turkish plural forms incorrect
--+--
 Reporter:  dave@…|Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Translations  |  Version:  1.3
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by aaugustin):

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


Comment:

 Closing "invalid" for the reason explained by Claude.

-- 
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] #15220: replace SelectFilter2.js with a jQuery plugin

[Django]

#15220: replace SelectFilter2.js with a jQuery plugin
-+-
 Reporter:  slurms   |Owner:  dbunskoek
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-

Comment (by julien):

 FYI, while working on #13614, I've used the latest patch from here and
 brought it up to date with current trunk.

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

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

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

[Django]

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

Comment (by julien):

 I bit the bullet and used the patch in #15220 as a basis to rewrite the
 widget as a jQuery plugin, which makes everything a lot easier to
 understand and work with. I've also added all the improvements made for
 that widget in trunk over the last months. I then refactored the code to
 fix this bug.

 However, as in the previous patch, while the bug seems to be fixed by this
 patch in Chrome (all Selenium tests pass), there is still an issue with
 Firefox (all Selenium tests pass except `test_back_button_bug_13614`).

 With this patch, in Firefox, if there are multiple filter widgets on the
 page, then only the first one keeps the selected values after pressing
 'Back'; all other widgets receive the initial values. Run the
 `test_back_button_bug_13614` test to get an illustration.

 I've spent a lot of time trying to debug this and I'm really stumped. I
 haven't been able to figure out why Firefox behaves that way yet. Any
 insight would be helpful.

-- 
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] r17649 - django/trunk/tests/regressiontests/admin_widgets

[noreply]

Author: julien
Date: 2012-03-03 20:50:58 -0800 (Sat, 03 Mar 2012)
New Revision: 17649

Modified:
   django/trunk/tests/regressiontests/admin_widgets/tests.py
Log:
Made the Selenium tests for the admin horizontal/vertical filter widgets a bit 
more thorough.

Modified: django/trunk/tests/regressiontests/admin_widgets/tests.py
===
--- django/trunk/tests/regressiontests/admin_widgets/tests.py   2012-03-04 
01:20:03 UTC (rev 17648)
+++ django/trunk/tests/regressiontests/admin_widgets/tests.py   2012-03-04 
04:50:58 UTC (rev 17649)
@@ -624,7 +624,8 @@
 for field_name in ['students', 'alumni']:
 from_box = '#id_%s_from' % field_name
 to_box = '#id_%s_to' % field_name
-choose_link = 'id_%s_add_link' % field_name
+choose_link = '#id_%s_add_link' % field_name
+remove_link = '#id_%s_remove_link' % field_name
 input = self.selenium.find_element_by_css_selector('#id_%s_input' 
% field_name)
 
 # Initial values
@@ -648,21 +649,40 @@
  str(self.cliff.id), str(self.jason.id),
  str(self.jenny.id), str(self.john.id)])
 
+# -
 # Check that chosing a filtered option sends it properly to the
 # 'to' box.
 input.send_keys('a')
 self.assertSelectOptions(from_box, [str(self.arthur.id), 
str(self.jason.id)])
 self.get_select_option(from_box, str(self.jason.id)).click()
-self.selenium.find_element_by_id(choose_link).click()
+self.selenium.find_element_by_css_selector(choose_link).click()
 self.assertSelectOptions(from_box, [str(self.arthur.id)])
+self.assertSelectOptions(to_box,
+[str(self.lisa.id), str(self.peter.id),
+ str(self.jason.id)])
+
+self.get_select_option(to_box, str(self.lisa.id)).click()
+self.selenium.find_element_by_css_selector(remove_link).click()
+self.assertSelectOptions(from_box,
+[str(self.arthur.id), str(self.lisa.id)])
+self.assertSelectOptions(to_box,
+[str(self.peter.id), str(self.jason.id)])
+
 input.send_keys([Keys.BACK_SPACE]) # Clear text box
 self.assertSelectOptions(from_box,
 [str(self.arthur.id), str(self.bob.id),
  str(self.cliff.id), str(self.jenny.id),
- str(self.john.id)])
+ str(self.john.id), str(self.lisa.id)])
 self.assertSelectOptions(to_box,
-[str(self.lisa.id), str(self.peter.id),
- str(self.jason.id)])
+[str(self.peter.id), str(self.jason.id)])
 
+# Save and check that everything is properly stored in the database ---
+self.selenium.find_element_by_xpath('//input[@value="Save"]').click()
+self.school = models.School.objects.get(id=self.school.id) # Reload 
from database
+self.assertEqual(list(self.school.students.all()),
+ [self.jason, self.peter])
+self.assertEqual(list(self.school.alumni.all()),
+ [self.jason, self.peter])
+
 class 
HorizontalVerticalFilterSeleniumChromeTests(HorizontalVerticalFilterSeleniumFirefoxTests):
 webdriver_class = 'selenium.webdriver.chrome.webdriver.WebDriver'
\ No newline at end of file

-- 
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] #17825: ImproperlyConfigured: You must enable 'django.core.context_processors.request' in TEMPLATE_CONTEXT_PROCESSORS

[Django]

#17825: ImproperlyConfigured: You must enable
'django.core.context_processors.request' in TEMPLATE_CONTEXT_PROCESSORS
---+--
 Reporter:  EvoTech|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.4-beta-1
 Severity:  Release blocker|   Resolution:  needsinfo
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by carljm):

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


Comment:

 Replying to [comment:3 EvoTech]:
 > Carljm, thanks for answer.
 >
 > Are you sure, that issue in contrib.auth and not in
 django.test.utils.override_settings() logic?
 >
 > I'm afaide, that some yet another 3rd application can kill data from
 settings...

 I'm fairly sure `override_settings` is working as designed. It only
 overrides the settings for the duration of those tests, which is what it
 should do and is fine. It's not "killing data from settings" in any
 persistent way.

 But I just realized that much of my comments here are wrong and based on
 an insufficiently careful scan of the changeset. ``TEMPLATE_DIRS`` are of
 course overridden for those tests both before and after r17598. Given
 that, I no longer understand how r17598 could cause tests to fail in your
 project. So I'm closing this needsinfo - can you paste the failure you are
 seeing since r17598, and your project's settings file?

 Clearly time for me to quit for the night...

-- 
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] #17825: ImproperlyConfigured: You must enable 'django.core.context_processors.request' in TEMPLATE_CONTEXT_PROCESSORS

[Django]

#17825: ImproperlyConfigured: You must enable
'django.core.context_processors.request' in TEMPLATE_CONTEXT_PROCESSORS
---+--
 Reporter:  EvoTech|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.4-beta-1
 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 EvoTech):

 Carljm, thanks for answer.

 Are you sure, that issue in contrib.auth and not in
 django.test.utils.override_settings() logic?

 I'm afaide, that some yet another 3rd application can kill data from
 settings...

-- 
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] #17627: contrib.admin.util is misnamed

[Django]

#17627: contrib.admin.util is misnamed
--+
 Reporter:  PaulM |Owner:  lukegb
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.admin |  Version:  SVN
 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 carljm):

 * needs_better_patch:  0 => 1


Comment:

 Thanks Luke. I'm not happy with the current solution in the patch for the
 ``import *`` problem, it's kind of ugly. When instances of ``import *``
 cause trouble, that's a golden opportunity to get rid of that instance of
 ``import *`` entirely.

 Also, I note an oddity in the patch in ``deprecation.txt`` - it's listed
 under a section for ``1.7`` but mentions ``1.8`` near the end of the
 paragraph. Normally we try not to be redundant in the text and just say
 "will be removed." not "will be removed in 1.X", since the relevant
 version is already at the header of the section.

-- 
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] #17825: ImproperlyConfigured: You must enable 'django.core.context_processors.request' in TEMPLATE_CONTEXT_PROCESSORS

[Django]

#17825: ImproperlyConfigured: You must enable
'django.core.context_processors.request' in TEMPLATE_CONTEXT_PROCESSORS
---+--
 Reporter:  EvoTech|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.4-beta-1
 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 carljm):

 Oh, I just realized that r17598 itself fixed a release-blocking regression
 (#16366).

 The more we have to isolate contrib-app tests from the project settings,
 the less justification there is for even having those tests run in
 anyone's project. Until we achieve perfect isolation, we'll keep getting
 reports of failures due to differences in someone's setup. Once we achieve
 perfect isolation, having those tests run by default just uselessly slows
 down people's test suites with extra tests that will never fail (unless
 they are mucking in contrib.auth's own codebase).

 It's possible there could be a few integration tests that are not isolated
 and must pass in any project where contrib.auth is functioning, but I
 doubt that it is even possible to write such tests and have them still be
 useful, given all the possible customizations of contrib.auth in a given
 project. Such integration tests should be provided by the project, which
 knows how their integration works, not by contrib.auth.

 So I think the real fix to this and #16366 is just to place contrib.auth's
 tests in Django's own test suite instead, or in a submodule of
 contrib.auth such that they only run if you place "contrib.auth.tests" in
 the installed apps.

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

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

Re: [Django] #17825: ImproperlyConfigured: You must enable 'django.core.context_processors.request' in TEMPLATE_CONTEXT_PROCESSORS

[Django]

#17825: ImproperlyConfigured: You must enable
'django.core.context_processors.request' in TEMPLATE_CONTEXT_PROCESSORS
---+--
 Reporter:  EvoTech|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.4-beta-1
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by carljm):

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


Comment:

 Yes, this is a problem. If the contrib.auth tests are really to be
 properly isolated, r17598 needed to go further and override
 ``TEMPLATE_DIRS`` as well and add test templates for the contrib.auth
 views. Of course, at that point there is little to no reason why the
 contrib.auth tests should be run in anyone's project, and they may as well
 be moved to Django's own test suite.

 Marking this a release blocker as it's a regression. If nothing else,
 r17598 should just be rolled back.

-- 
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] #17825: ImproperlyConfigured: You must enable 'django.core.context_processors.request' in TEMPLATE_CONTEXT_PROCESSORS

[Django]

#17825: ImproperlyConfigured: You must enable
'django.core.context_processors.request' in TEMPLATE_CONTEXT_PROCESSORS
---+
 Reporter:  EvoTech|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  1.4-beta-1
 Severity:  Release blocker|   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 After revision r17598 django.core.context_processors.request is lost from
 the settings.TEMPLATE_CONTEXT_PROCESSORS.
 And all tests, that uses "requiest", - fall.

-- 
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] r17648 - in django/trunk: django/contrib/admin tests/regressiontests/admin_widgets

[noreply]

Author: julien
Date: 2012-03-03 17:20:03 -0800 (Sat, 03 Mar 2012)
New Revision: 17648

Modified:
   django/trunk/django/contrib/admin/tests.py
   django/trunk/tests/regressiontests/admin_widgets/tests.py
Log:
Added more thorough Selenium tests for the admin horizontal/vertical filter 
widgets.

Modified: django/trunk/django/contrib/admin/tests.py
===
--- django/trunk/django/contrib/admin/tests.py  2012-03-03 22:54:55 UTC (rev 
17647)
+++ django/trunk/django/contrib/admin/tests.py  2012-03-04 01:20:03 UTC (rev 
17648)
@@ -94,4 +94,12 @@
 actual_values = []
 for option in options:
 actual_values.append(option.get_attribute('value'))
-self.assertEqual(values, actual_values)
\ No newline at end of file
+self.assertEqual(values, actual_values)
+
+def has_css_class(self, selector, klass):
+"""
+Returns True if the element identified by `selector` has the CSS class
+`klass`.
+"""
+return (self.selenium.find_element_by_css_selector(selector)
+.get_attribute('class').find(klass) != -1)
\ No newline at end of file

Modified: django/trunk/tests/regressiontests/admin_widgets/tests.py
===
--- django/trunk/tests/regressiontests/admin_widgets/tests.py   2012-03-03 
22:54:55 UTC (rev 17647)
+++ django/trunk/tests/regressiontests/admin_widgets/tests.py   2012-03-04 
01:20:03 UTC (rev 17648)
@@ -480,7 +480,19 @@
 self.school = models.School.objects.create(name='School of Awesome')
 super(HorizontalVerticalFilterSeleniumFirefoxTests, self).setUp()
 
-def execute_basic_operations(self, field_name, mode):
+def assertActiveButtons(self, mode, field_name, choose, remove,
+ choose_all=None, remove_all=None):
+choose_link = '#id_%s_add_link' % field_name
+choose_all_link = '#id_%s_add_all_link' % field_name
+remove_link = '#id_%s_remove_link' % field_name
+remove_all_link = '#id_%s_remove_all_link' % field_name
+self.assertEqual(self.has_css_class(choose_link, 'active'), choose)
+self.assertEqual(self.has_css_class(remove_link, 'active'), remove)
+if mode == 'horizontal':
+self.assertEqual(self.has_css_class(choose_all_link, 'active'), 
choose_all)
+self.assertEqual(self.has_css_class(remove_all_link, 'active'), 
remove_all)
+
+def execute_basic_operations(self, mode, field_name):
 from_box = '#id_%s_from' % field_name
 to_box = '#id_%s_to' % field_name
 choose_link = 'id_%s_add_link' % field_name
@@ -495,6 +507,7 @@
  str(self.jenny.id), str(self.john.id)])
 self.assertSelectOptions(to_box,
 [str(self.lisa.id), str(self.peter.id)])
+self.assertActiveButtons(mode, field_name, False, False, True, True)
 
 # Click 'Choose all' --
 if mode == 'horizontal':
@@ -511,6 +524,7 @@
  str(self.arthur.id), str(self.bob.id),
  str(self.cliff.id), str(self.jason.id),
  str(self.jenny.id), str(self.john.id)])
+self.assertActiveButtons(mode, field_name, False, False, False, True)
 
 # Click 'Remove all' --
 if mode == 'horizontal':
@@ -527,13 +541,16 @@
  str(self.cliff.id), str(self.jason.id),
  str(self.jenny.id), str(self.john.id)])
 self.assertSelectOptions(to_box, [])
+self.assertActiveButtons(mode, field_name, False, False, True, False)
 
 # Choose some options 
 self.get_select_option(from_box, str(self.lisa.id)).click()
 self.get_select_option(from_box, str(self.jason.id)).click()
 self.get_select_option(from_box, str(self.bob.id)).click()
 self.get_select_option(from_box, str(self.john.id)).click()
+self.assertActiveButtons(mode, field_name, True, False, True, False)
 self.selenium.find_element_by_id(choose_link).click()
+self.assertActiveButtons(mode, field_name, False, False, True, True)
 
 self.assertSelectOptions(from_box,
 [str(self.peter.id), str(self.arthur.id),
@@ -545,7 +562,9 @@
 # Remove some options -
 self.get_select_option(to_box, str(self.lisa.id)).click()
 self.get_select_option(to_box, str(self.bob.id)).click()
+self.assertActiveButtons(mode, field_name, False, True, True, True)
 self.selenium.find_element_by_id(remove_link).click()
+self.assertActiveButtons(mode, field_name, False, False, True, True)
 
 self.assertSelectOptions(from_box,

Re: [Django] #15802: Django stops functioning when the database (PostgreSQL) closes the connection

[Django]

#15802: Django stops functioning when the database (PostgreSQL) closes the
connection
-+-
 Reporter:  Rick.van.Hattem@…|Owner:
 Type:  Bug  |  Honza_Kral
Component:  Database layer   |   Status:  reopened
  (models, ORM)  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  database, postgres,  | Triage Stage:  Accepted
  postgresql, connection, closed |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by piro):

 Replying to [comment:13 anonymous]:

 >  * Convince the psycopg2 guys that their interpretation of pep-0249 is
 wrong as it seems that the mysql guys interpreted the following different
 (from pep-0249):

 I've tried to do that: close() should be idempotent. But the reference
 DBAPI test suite fails as it explicitly check that the second close()
 raises an exception. I've discussed about the problem in the DBSIG
 , but
 never got to the point to fix the test suite. I should really write to
 Stuart Bishop about 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] #16455: Postgis 2.0 Compatibility

[Django]

#16455: Postgis 2.0 Compatibility
-+
 Reporter:  ckarrie  |Owner:  jbronn
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  postgis 2.0  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by kmike):

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

[Changeset] r17647 - django/trunk/docs/releases

[noreply]

Author: aaugustin
Date: 2012-03-03 14:54:55 -0800 (Sat, 03 Mar 2012)
New Revision: 17647

Modified:
   django/trunk/docs/releases/1.4.txt
Log:
Linked to the FAQ from the release notes.


Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2012-03-03 22:41:21 UTC (rev 17646)
+++ django/trunk/docs/releases/1.4.txt  2012-03-03 22:54:55 UTC (rev 17647)
@@ -479,7 +479,8 @@
 
 Time zone support is enabled by default in new projects created with
 :djadmin:`startproject`. If you want to use this feature in an existing
-project, read the :ref:`migration guide `.
+project, read the :ref:`migration guide `. If you
+encounter problems, there's a helpful :ref:`FAQ `.
 
 HTML comparisons in tests
 ~

-- 
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] r17646 - django/trunk/docs/topics/i18n

[noreply]

Author: aaugustin
Date: 2012-03-03 14:41:21 -0800 (Sat, 03 Mar 2012)
New Revision: 17646

Modified:
   django/trunk/docs/topics/i18n/timezones.txt
Log:
Fixed a typo in the time zone docs. Thanks Ramiro.


Modified: django/trunk/docs/topics/i18n/timezones.txt
===
--- django/trunk/docs/topics/i18n/timezones.txt 2012-03-03 22:02:23 UTC (rev 
17645)
+++ django/trunk/docs/topics/i18n/timezones.txt 2012-03-03 22:41:21 UTC (rev 
17646)
@@ -685,7 +685,7 @@
the datetime in UTC returned by :func:`django.utils.timezone.now` will be
sufficient.
 
-   For the shake of completeness, if you really wanted the current time in the
+   For the sake of completeness, if you really wanted the current time in the
local time zone, here's how you would obtain it::
 
>>> import datetime

-- 
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] #17605: It is not documented how to work with ManyToMany relations

[Django]

#17605: It is not documented how to work with ManyToMany relations
-+
 Reporter:  kmike|Owner:  ramiro
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by aaugustin):

 * needs_better_patch:  0 => 1


Comment:

 The style shows that these documents used to be doctests, but it's a good
 basis IMO.

 __topics/db/models.txt__

 * This page still refers to the "Many-to-one relationship model tests",
 but that link is pointing to a regular documentation page. Use the same
 wording as the other "See also" blocks?

 __topics/db/examples/many_to_one.txt__

 * `a = Article(id=None, ...`: this isn't idiomatic; I'd skip the `id`
 kwarg entirely.
 * "Article objects have access to their related Reporter objects:": this
 was demonstrated just above, I'd reorganize this part a bit
 * `>>> Article.objects.filter(reporter=1)`: I didn't know this was
 supported, and it feels unclean. Plus, there are two ways to do the same
 thing. Do we really want to document this possibility?
 * `>>> Reporter.objects.filter(article=1)`: same comment

 __topics/db/examples/many_to_many.txt__

 * "Add a Publication directly via publications.add...": shouldn't that be
 "publications.create"?
 * `>>> Article.objects.filter(publications=1)`: same comment again
 * `publications__in=[1,2]`: missing space after the comma
 * `publications__in=[p1,p2]`: missing space after the comma
 * `>>> Publication.objects.filter(article=1)`: same comment again
 * `article__in=[1,2]`: missing space after the comma
 * `article__in=[a1,a2]`: missing space after the comma
 * "After the delete, the QuerySet cache needs to be cleared, and the
 referenced objects should be gone": this sounds like an internal
 implementation detail, not something a developer using Django should worry
 about

 __topics/db/examples/one_to_one.txt__

 * "Restaurant.objects.all()" should be in fixed width font.

 I hope this helps!

-- 
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] #17823: Add nolock support to queryset API

[Django]

#17823: Add nolock support to queryset API
-+-
 Reporter:  mlissner |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 A quick question: what does a non-locking query exactly mean? I know data
 modification does lock the object for other modifications, but why would
 read operations do that? So, how would this be done in raw SQL? Pointers
 to documentation of different database vendors welcome.

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

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

[Changeset] r17645 - django/trunk/docs/topics/i18n

[noreply]

Author: aaugustin
Date: 2012-03-03 14:02:23 -0800 (Sat, 03 Mar 2012)
New Revision: 17645

Modified:
   django/trunk/docs/topics/i18n/timezones.txt
Log:
Fixed #17738 -- Extended the time zone documentation with a FAQ. Thanks Anssi 
for the questions and Jannis for the review.


Modified: django/trunk/docs/topics/i18n/timezones.txt
===
--- django/trunk/docs/topics/i18n/timezones.txt 2012-03-03 21:50:49 UTC (rev 
17644)
+++ django/trunk/docs/topics/i18n/timezones.txt 2012-03-03 22:02:23 UTC (rev 
17645)
@@ -6,6 +6,8 @@
 
 .. versionadded:: 1.4
 
+.. _time-zones-overview:
+
 Overview
 
 
@@ -30,8 +32,12 @@
 
 Time zone support is disabled by default. To enable it, set :setting:`USE_TZ =
 True ` in your settings file. Installing pytz_ is highly recommended,
-but not mandatory.
+but not mandatory. It's as simple as::
 
+.. code-block::
+
+$ sudo pip install pytz
+
 .. note::
 
 The default :file:`settings.py` file created by :djadmin:`django-admin.py
@@ -44,6 +50,9 @@
 controls if Django should activate format localization. See
 :doc:`/topics/i18n/formatting` for more details.
 
+If you're stumbling on a particular problem, start with the :ref:`time zone
+FAQ `.
+
 Concepts
 
 
@@ -132,15 +141,9 @@
 The **default time zone** is the time zone defined by the :setting:`TIME_ZONE`
 setting.
 
-When pytz_ is available, Django loads the definition of the default time zone
-from the `tz database`_. This is the most accurate solution. Otherwise, it
-relies on the difference between local time and UTC, as reported by the
-operating system, to compute conversions. This is less reliable, especially
-around DST transitions.
-
 The **current time zone** is the time zone that's used for rendering.
 
-You should set it to the end user's actual time zone with
+You should set the current time zone to the end user's actual time zone with
 :func:`~django.utils.timezone.activate`. Otherwise, the default time zone is
 used.
 
@@ -173,7 +176,7 @@
 Most websites who care about time zones just ask users in which time zone they
 live and store this information in the user's profile. For anonymous users,
 they use the time zone of their primary audience or UTC. pytz_ provides
-helpers, like a list of time zones per country, that you can use to pre-select
+helpers_, like a list of time zones per country, that you can use to pre-select
 the most likely choices.
 
 Here's an example that stores the current timezone in the session. (It skips
@@ -217,6 +220,8 @@
 
 
 
+.. _time-zones-in-forms:
+
 Time zone aware input in forms
 ==
 
@@ -464,6 +469,241 @@
 Or, if they're small enough, you can simply edit them to add the UTC offset
 that matches your :setting:`TIME_ZONE` to each serialized datetime.
 
+.. _time-zones-faq:
+
+FAQ
+===
+
+Setup
+-
+
+1. **I don't need multiple time zones. Should I enable time zone support?**
+
+   Yes. When time zone support is enabled, Django uses a more accurate model
+   of local time. This shields you from subtle and unreproducible bugs around
+   daylight saving time (DST) transitions. Remember that your website runs 
24/7!
+
+   In this regard, time zones is comparable to ``unicode`` in Python. At first
+   it's hard. You get encoding and decoding errors. Then you learn the rules.
+   And some problems disappear -- you never get mangled output again when your
+   application receives non-ASCII input.
+
+   When you enable time zone support, you'll encounter some errors because
+   you're using naive datetimes where Django expects aware datetimes. Such
+   errors show up when running tests and they're easy to fix. You'll quickly
+   learn how to avoid invalid operations.
+
+   On the other hand, bugs caused by the lack of time zone support are much
+   harder to prevent, diagnose and fix. Anything that involves scheduled tasks
+   or datetime arithmetic is a candidate for subtle bugs that will bite you
+   only once or twice a year.
+
+   For these reasons, time zone support is enabled by default in new projects,
+   and you should keep it unless you have a very good reason not to.
+
+2. **I've enabled time zone support, am I safe?**
+
+   Maybe. You're better protected from DST-related bugs, but you can still
+   shoot yourself in the foot by carelessly turning naive datetimes into aware
+   datetimes, and vice-versa.
+
+   If your application connects to other systems, for instance if it queries
+   a webservice, make sure datetimes are properly specified. To transmit
+   datetimes safely, their representation should include the UTC offset, or
+   their values should be in UTC (or both!).
+
+   Finally, our calendar system contains interesting traps for computers::
+
+   >>> import datetime
+   >>> def substract_one_year(value):   # DON'T DO THAT!
+   ... return value.replace(year=value.year - 1)
+   >>> one_year_before(datetime.datetime(2012, 3

Re: [Django] #17738: Add a time zone FAQ

[Django]

#17738: Add a time zone FAQ
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:
Component:  Documentation|  1.4-beta-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 In [17645]:
 {{{
 #!CommitTicketReference repository="" revision="17645"
 Fixed #17738 -- Extended the time zone documentation with a FAQ. Thanks
 Anssi for the questions and Jannis for the review.
 }}}

-- 
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] #17824: Add generic pre/post_modify signal

[Django]

#17824: Add generic pre/post_modify signal
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #17824: Add generic pre/post_modify signal

[Django]

#17824: Add generic pre/post_modify signal
--+
 Reporter:  akaariai  |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 There might be some value in a new model signal: pre/post_modify. The
 signal would have six arguments:
   - sender: the model class under DML.
   - objs: an possibly empty iterable containing all the objects going to
 be modified. Accessing the iterable can trigger a query.
   - action: one of "save","delete","update","bulk_create" or "raw_sql".
   - action_args: this is the args passed to the
 save/delete/update/bulk_create command.
   - raw: True if the signal fired because of fixture loading.
   - db: The database alias under modification.

 Usages:
   - Currently it is somewhat hard to do cache invalidation, Haystack
 search index rebuilding etc. especially if you need to also check related
 model changes. This would give you one point where you can do the
 invalidation/rebuilding.
   - The current signals framework is only halfway complete: you can catch
 some modifications done by Django, but not all. The above would allow you
 to block some operations categorically, or actually do proper auditing in
 Python code.
   - You could make a DB read-only in one simple step: a pre_modify signal
 raising `"ReadOnlyDBError"` for all senders.

 There is one use-case which is problematic: bulk_insert. Here the objs are
 not going to have PK set, so this will cause problems for Haystack
 indexing just for an example. I think it would be possible to implement
 the signal in such a way that the caller could raise a
 "`IDidItForYouException`", or to modify the given objs iterator in a way
 that it removes some objects from the iterator. Both of these would make
 it possible to convert the bulk_insert into regular .save() operations if
 the caller absolutely needs that for one reason or another.

 The biggest reason this signal would be nice is that this allows total
 data modifying control without overhead: for example .update() can't fire
 pre/post_save signals as that would be really costly for large batches.
 Now, if you pass the queryset being updated into the signal, and in
 addition the kwargs for .update() you could possibly schedule reindexing
 or do cache invalidtation by just fetching all the PK's from the queryset
 which isn't that expensive. Or you could do auditing by running another
 .update() from the signal. If there is nobody interested in the operation,
 the signal costs you almost nothing.

 This obviously needs discussion at django-developers, but just now isn't
 the right time for 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.

[Changeset] r17644 - in django/trunk/docs: releases topics

[noreply]

Author: ramiro
Date: 2012-03-03 13:50:49 -0800 (Sat, 03 Mar 2012)
New Revision: 17644

Modified:
   django/trunk/docs/releases/1.4.txt
   django/trunk/docs/topics/testing.txt
Log:
Added a blurb about new SimpleTestCase class to release notes.

Also, tweaked the cross-referencing of `django.test` symbols.

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2012-03-03 21:34:51 UTC (rev 17643)
+++ django/trunk/docs/releases/1.4.txt  2012-03-03 21:50:49 UTC (rev 17644)
@@ -484,17 +484,17 @@
 HTML comparisons in tests
 ~
 
-The :class:`~django.test.testcase.TestCase` base class now has some helpers to
+The base classes in :mod:`django.test` now have some helpers to
 compare HTML without tripping over irrelevant differences in whitespace,
 argument quoting/ordering and closing of self-closing tags. You can either
 compare HTML directly with the new
-:meth:`~django.test.testcase.TestCase.assertHTMLEqual` and
-:meth:`~django.test.testcase.TestCase.assertHTMLNotEqual` assertions, or use
+:meth:`~django.test.SimpleTestCase.assertHTMLEqual` and
+:meth:`~django.test.SimpleTestCase.assertHTMLNotEqual` assertions, or use
 the ``html=True`` flag with
-:meth:`~django.test.testcase.TestCase.assertContains` and
-:meth:`~django.test.testcase.TestCase.assertNotContains` to test whether the
-client's response contains a given HTML fragment. See the :ref:`assertion
-documentation` for more.
+:meth:`~django.test.TestCase.assertContains` and
+:meth:`~django.test.TestCase.assertNotContains` to test whether the
+client's response contains a given HTML fragment. See the :ref:`assertions
+documentation ` for more.
 
 Two new date format strings
 ~~~
@@ -614,6 +614,12 @@
   :attr:`Sitemap.protocol ` class
   attribute.
 
+* A new :class:`django.test.SimpleTestCase` subclass of
+  :class:`unittest.TestCase`
+  that is comparatively lighter than :class:`django.test.TestCase` and
+  company. It can be useful in testing scenarios where e.g. no database
+  interaction is needed. See :ref:`testcase_hierarchy_diagram`.
+
 Backwards incompatible changes in 1.4
 =
 
@@ -1016,8 +1022,8 @@
 ~~~
 
 It's now possible to check whether a template was used within a block of
-code with :meth:`~django.test.testcase.TestCase.assertTemplateUsed` and
-:meth:`~django.test.testcase.TestCase.assertTemplateNotUsed`. And they
+code with :meth:`~django.test.test.TestCase.assertTemplateUsed` and
+:meth:`~django.test.test.TestCase.assertTemplateNotUsed`. And they
 can be used as a context manager::
 
 with self.assertTemplateUsed('index.html'):

Modified: django/trunk/docs/topics/testing.txt
===
--- django/trunk/docs/topics/testing.txt2012-03-03 21:34:51 UTC (rev 
17643)
+++ django/trunk/docs/topics/testing.txt2012-03-03 21:50:49 UTC (rev 
17644)
@@ -1089,9 +1089,13 @@
 Normal Python unit test classes extend a base class of
 :class:`unittest.TestCase`. Django provides a few extensions of this base 
class:
 
-.. image:: _images/django_unittest_classes_hierarchy.png
-   :alt: Django hierarchy of unit testing helper classes (TestCase subclasses)
+.. _testcase_hierarchy_diagram:
 
+.. figure:: _images/django_unittest_classes_hierarchy.png
+   :alt: Hierarchy of Django unit testing classes (TestCase subclasses)
+
+   Hierarchy of Django unit testing classes
+
 .. class:: TestCase()
 
 This class provides some additional capabilities that can be useful for testing
@@ -1166,19 +1170,20 @@
 basic functionality like:
 
 * Saving and restoring the Python warning machinery state.
-* Checking that a callable :meth:`raises a certain exeception 
`.
-* :meth:`Testing form field rendering `.
+* Checking that a callable :meth:`raises a certain exception 
`.
+* :meth:`Testing form field rendering `.
+* Testing server :ref:`HTML responses for the presence/lack of a given 
fragment `.
+* The ability to run tests with :ref:`modified settings `
 
 If you need any of the other more complex and heavyweight Django-specific
 features like:
 
-* The ability to run tests with :ref:`modified settings `
 * Using the :attr:`~TestCase.client` :class:`~django.test.client.Client`.
 * Testing or using the ORM.
 * Database :attr:`~TestCase.fixtures`.
 * Custom test-time :attr:`URL maps `.
 * Test :ref:`skipping based on database backend features `.
-* Our specialized :ref:`assert* ` metods.
+* The remaining specialized :ref:`assert* ` methods.
 
 then you should use :class:`~django.test.TransactionTestCase` or
 :class:`~django.test.TestCase` instead.
@@ -1515,7 +1520,7 @@
 details that may help you to identify the location and cause of an failure in
 your test suite.
 
-.. method:: TestCase.assertRaisesMessage(expected_exception, expected_message, 
callable_obj=None,

Re: [Django] #17375: 'makemessages' ignores plural from 'blocktrans'

[Django]

#17375: 'makemessages' ignores plural from 'blocktrans'
--+
 Reporter:  ahagenbruch   |Owner:  pigletto
 Type:  Bug   |   Status:  assigned
Component:  Internationalization  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by pigletto):

 OK, I'm going to update it soon

-- 
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] r17643 - in django/trunk: django/core/serializers tests/regressiontests/serializers_regress

[noreply]

Author: jezdez
Date: 2012-03-03 13:34:51 -0800 (Sat, 03 Mar 2012)
New Revision: 17643

Modified:
   django/trunk/django/core/serializers/base.py
   django/trunk/tests/regressiontests/serializers_regress/models.py
   django/trunk/tests/regressiontests/serializers_regress/tests.py
Log:
Fixed #17717 (again) -- Used the new API for concrete models added in r17573. 
Many thanks to Simon Charette and Anssi K?\195?\164?\195?\164ri?\195?\164inen.

Modified: django/trunk/django/core/serializers/base.py
===
--- django/trunk/django/core/serializers/base.py2012-03-03 19:57:25 UTC 
(rev 17642)
+++ django/trunk/django/core/serializers/base.py2012-03-03 21:34:51 UTC 
(rev 17643)
@@ -43,8 +43,8 @@
 self.start_object(obj)
 # Use the concrete parent class' _meta instead of the object's 
_meta
 # This is to avoid local_fields problems for proxy models. Refs 
#17717.
-concrete_class = obj._meta.proxy_for_model or obj.__class__
-for field in concrete_class._meta.local_fields:
+concrete_model = obj._meta.concrete_model
+for field in concrete_model._meta.local_fields:
 if field.serialize:
 if field.rel is None:
 if self.selected_fields is None or field.attname in 
self.selected_fields:
@@ -52,7 +52,7 @@
 else:
 if self.selected_fields is None or field.attname[:-3] 
in self.selected_fields:
 self.handle_fk_field(obj, field)
-for field in concrete_class._meta.many_to_many:
+for field in concrete_model._meta.many_to_many:
 if field.serialize:
 if self.selected_fields is None or field.attname in 
self.selected_fields:
 self.handle_m2m_field(obj, field)

Modified: django/trunk/tests/regressiontests/serializers_regress/models.py
===
--- django/trunk/tests/regressiontests/serializers_regress/models.py
2012-03-03 19:57:25 UTC (rev 17642)
+++ django/trunk/tests/regressiontests/serializers_regress/models.py
2012-03-03 21:34:51 UTC (rev 17643)
@@ -263,6 +263,10 @@
 class Meta:
 proxy = True
 
+class ProxyProxyBaseModel(ProxyBaseModel):
+class Meta:
+proxy = True
+
 class LengthModel(models.Model):
 data = models.IntegerField()
 

Modified: django/trunk/tests/regressiontests/serializers_regress/tests.py
===
--- django/trunk/tests/regressiontests/serializers_regress/tests.py 
2012-03-03 19:57:25 UTC (rev 17642)
+++ django/trunk/tests/regressiontests/serializers_regress/tests.py 
2012-03-03 21:34:51 UTC (rev 17643)
@@ -41,8 +41,8 @@
 GenericIPAddressPKData, PhonePKData, PositiveIntegerPKData,
 PositiveSmallIntegerPKData, SlugPKData, SmallPKData, USStatePKData,
 AutoNowDateTimeData, ModifyingSaveData, InheritAbstractModel, BaseModel,
-ExplicitInheritBaseModel, InheritBaseModel, ProxyBaseModel, BigIntegerData,
-LengthModel, Tag, ComplexModel)
+ExplicitInheritBaseModel, InheritBaseModel, ProxyBaseModel,
+ProxyProxyBaseModel, BigIntegerData, LengthModel, Tag, ComplexModel)
 
 # A set of functions that can be used to recreate
 # test data objects of various kinds.
@@ -410,11 +410,14 @@
 
 def test_serialize_proxy_model(self):
 BaseModel.objects.create(parent_data=1)
-base_objects  = BaseModel.objects.all()
+base_objects = BaseModel.objects.all()
 proxy_objects = ProxyBaseModel.objects.all()
-base_data  = serializers.serialize("json", base_objects)
+proxy_proxy_objects = ProxyProxyBaseModel.objects.all()
+base_data = serializers.serialize("json", base_objects)
 proxy_data = serializers.serialize("json", proxy_objects)
+proxy_proxy_data = serializers.serialize("json", proxy_proxy_objects)
 self.assertEqual(base_data, proxy_data.replace('proxy', ''))
+self.assertEqual(base_data, proxy_proxy_data.replace('proxy', ''))
 
 
 def serializerTest(format, 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] #17717: django.core.serializers.serialize doesn't deal with proxy models

[Django]

#17717: django.core.serializers.serialize doesn't deal with proxy models
-+-
 Reporter:  lakin|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core |  Version:  1.1
  (Serialization)|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jezdez):

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


Comment:

 In [17643]:
 {{{
 #!CommitTicketReference repository="" revision="17643"
 Fixed #17717 (again) -- Used the new API for concrete models added in
 r17573. Many thanks to Simon Charette and Anssi Kääriäinen.
 }}}

-- 
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] #17738: Add a time zone FAQ

[Django]

#17738: Add a time zone FAQ
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Documentation|  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * has_patch:  0 => 1
 * 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] #17788: bulk_create() "too many SQL variables" error

[Django]

#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 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 akaariai):

 Attached is a patch that fixes the bulk_create issue. I used
 get_batch_size which can inspect the fields and the objects in the query.

 The patch also implements a default limit of 10 objects in one batch.
 Dropping one zero from the end would be wise, or if you prefer no limit,
 thats OK too for me. It would be trivial to implement batch_size kwarg for
 bulk_create if that is wanted down the road.

 In addition to the .delete() there is also prefetch_related which doesn't
 work if the inner sets are large enough (note: haven't actually tested).
 My opinion is that these aren't critical issues, but it would be nice to
 abstract the backend differences away if possible. However there is going
 to be always one issue: `id__in` queries can not be abstracted (splitting
 the query breaks sorting), so there will always be cases where SQLite
 doesn't work correctly.

 I noticed one issue with the bulk_create feature which might need some
 attention. It uses some effort to allow mixing of pk set / pk not set
 objects in one batch. In my opinion that is downright dangerous to allow,
 as the pk field must be autofield for the insert to work. Saving self-
 defined values to an autofield is something to be avoided, as that can
 break the sequence. It is fine to do bulk inserts with autofield PK set.
 Assume the user knows what he is doing, maybe he is going to reset the PK
 sequence after the operation or something. But I can't see any valid use
 case for mixing PK set and PK not set objects in one batch. The last added
 test in the patch doesn't work on SQLite for the very reason that mixing
 things in this way isn't safe. So, my question is, should this be
 disallowed? After 1.4 is released that can't be done. This isn't anything
 critical IMHO, but it would be good to discourage unsafe coding practices.

-- 
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] #17717: django.core.serializers.serialize doesn't deal with proxy models

[Django]

#17717: django.core.serializers.serialize doesn't deal with proxy models
-+-
 Reporter:  lakin|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Core |  Version:  1.1
  (Serialization)|   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * stage:  Accepted => Ready for checkin


Comment:

 Yes, that should be fixed. Now proxy_for_model is the actual proxied
 model, so as written the patch isn't correct any more. That is my failing,
 as I should have written it using the while {{{ opts._proxy_for_model:
 opts = opts._proxy_for_model._meta }}} idiom instead of assuming the buggy
 behavior in the patch.

 I tested the patch and without the fix it fails, with the fix in the patch
 it succeeds. I quickly skimmed through it and it seems ready for checkin
 to me.

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

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

[Django] #17823: Add nolock support to queryset API

[Django]

#17823: Add nolock support to queryset API
--+
 Reporter:  mlissner  |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 In a number of circumstances, it would be great if there was a way of
 designating a query as non-locking:
  - the sitemaps API creates locking queries on MySQL. On a large site with
 thousands of pages, this query thus stops the database until the search
 crawler has gotten its fill of sitemaps.
  - API queries - My project has an API that generates dump files for users
 so that they can export the data from the site. These queries are pretty
 slow, and unfortunately they too are locking, even though they don't need
 to be.
  - deep pagination - on a site with very deep pagination, the offset
 queries can be quite slow. I believe these are locking queries too,
 creating problems.

 I took a look at implementing this myself, but got rather lost in the
 query code very quickly. I know we can do this via raw queries, but that
 comes with a good deal of complication (e.g., things like the sitemaps and
 pagination are hard to re-implement using raw queries).

 Not sure how this would fit into the current API, but I'd love to have it
 available down the road. Happy to help implement if possible, but I'll
 need guidance.

-- 
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] #17803: Field name with underscore means label not correctly shown in form

[Django]

#17803: Field name with underscore means label not correctly shown in form
+--
 Reporter:  phoebebright@…  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Uncategorized   |  Version:  1.3
 Severity:  Normal  |   Resolution:  worksforme
 Keywords:  form, label | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Description changed by ramiro:

Old description:

> Is this a bug?
>
> If I have this in my model:
>
> account_type = models.CharField(_('Type of Business'), max_length=25,
> blank=True, null=True, help_text='What would your heading in a Directory
> be')
>
> The in a model form the field name is "Account type" and there is no help
> text
> If I change it to:
>
> accounttype = models.CharField(_('Type of Business'), max_length=25,
> blank=True, null=True, help_text='What would your heading in a Directory
> be')
>
> Form correctly has label of Type of Business and help text is displayed.
>
> BUT it is not consistent,
>
> This is the form:
> class NameForm(forms.ModelForm):
>

> class Meta:
> model = Account
> fields = ('name', 'contact_details','accounttype','turnover')
>
> And this is another field with an underscore and it displays the label
> and help text correctly:
>
> contact_details = models.TextField(_('Contact and Name'), blank=True,
> null=True, help_text='Actual Business Name and email/telephone if
> different from yours.')
>

>

>
> I can dig some more if this might be a bug.
> Using current version 1.3.1 of django.

New description:

 Is this a bug?

 If I have this in my model:
 {{{
 account_type = models.CharField(_('Type of Business'), max_length=25,
 blank=True, null=True, help_text='What would your heading in a Directory
 be')
 }}}
 The in a model form the field name is "Account type" and there is no help
 text.

 If I change it to:
 {{{
 accounttype = models.CharField(_('Type of Business'), max_length=25,
 blank=True, null=True, help_text='What would your heading in a Directory
 be')
 }}}
 Form correctly has label of Type of Business and help text is displayed.

 BUT it is not consistent,

 This is the form:
 {{{
 class NameForm(forms.ModelForm):

 class Meta:
 model = Account
 fields = ('name', 'contact_details','accounttype','turnover')
 }}}
 And this is another field with an underscore and it displays the label and
 help text correctly:
 {{{
 contact_details = models.TextField(_('Contact and Name'), blank=True,
 null=True, help_text='Actual Business Name and email/telephone if
 different from yours.')
 }}}

 I can dig some more if this might be a bug.
 Using current version 1.3.1 of django.

--

-- 
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] #17717: django.core.serializers.serialize doesn't deal with proxy models

[Django]

#17717: django.core.serializers.serialize doesn't deal with proxy models
--+
 Reporter:  lakin |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  Core (Serialization)  |  Version:  1.1
 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
--+
Changes (by jezdez):

 * status:  closed => reopened
 * resolution:  fixed =>
 * stage:  Ready for checkin => Accepted


Comment:

 Oh, yeah, I didn't see the changes done in r17573, this new
 "concrete_model" property might indeed fix this easier. Re-opening..

-- 
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] #17717: django.core.serializers.serialize doesn't deal with proxy models

[Django]

#17717: django.core.serializers.serialize doesn't deal with proxy models
-+-
 Reporter:  lakin|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core |  Version:  1.1
  (Serialization)|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * cc: charette.s@… (added)


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

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

Re: [Django] #17717: django.core.serializers.serialize doesn't deal with proxy models

[Django]

#17717: django.core.serializers.serialize doesn't deal with proxy models
-+-
 Reporter:  lakin|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core |  Version:  1.1
  (Serialization)|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 Now that there's a `concrete_class` property and that `proxy_for_model` is
 actually a proxy chain we should probably just get it from there?

 Correct me if I'm wrong but the patch checked in r17640 will fail for
 proxy of a proxy model.

 Should the patch be checked out and corrected with additional tests?

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

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

Re: [Django] #17738: Add a time zone FAQ

[Django]

#17738: Add a time zone FAQ
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Documentation|  1.4-beta-1
 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):

 I've integrated some questions as is in the patch. Here's why I altered or
 didn't keep others.

 [[BR]]

 >   - Q: How do I activate a time zone? A: use activate(timezone)

 It's easy to locate "Selecting the current time zone" in the sidebar. I
 don't find it useful to repeat that information in the FAQ.

 [[BR]]

 >   - Q: I have this string "2012-02-21 10:28:45". It is in
 `Europe/Helsinki` time zone. How do I correctly turn that into a aware
 datetime? A: ...
 >   - Q: How about it is just , any difference here? A: As above, but you
 can get the current time zone by get_current_timezone()

 I kept the first question, because the value may come from an external,
 naive API.
 I left out the second one because user input is supposed to come through
 forms, and the form layers deals with the conversion for you. I don't want
 to suggest emulating built-in functionality.

 [[BR]]

 >   - Q: How do I get a datetime in my timezone? A: You can get it by
 using localtime(value). However, are you sure you want to? In most
 situations it is better to handle the datetimes in UTC, and just display
 it in local time zone.

 localtime was specifically written for use by the template engine. I've
 decided to remove it from the public API, because it performs lots of
 template-specific checks and then just calls
 `value.astimezone(get_current_timezone())`.

 [[BR]]

 >   - Q: How do I compare datetimes correctly? A: Comparing two UTC-
 datetimes is easy: it just works. However, if you want to compare if two
 datetimes happened on the same day/month, you most likely want to do it in
 the user's time zone: convert first to localtime, then compare the local
 dates. For example, is the dt's date today? localtime(dt).date() ==
 localtime(now()).date()?

 The real difficulty is that, contrary to common assumptions, an aware
 datetime doesn't have a deterministic date -- that is, you can have ``dt1
 == dt2`` but ``dt1.date() != dt2.date()``. This is already covered in
 another question (date of last edit)

-- 
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] r17642 - in django/trunk: django/utils docs/ref

[noreply]

Author: aaugustin
Date: 2012-03-03 11:57:25 -0800 (Sat, 03 Mar 2012)
New Revision: 17642

Modified:
   django/trunk/django/utils/timezone.py
   django/trunk/docs/ref/utils.txt
Log:
Made django.utils.timezone.localtime a private API -- it's too specific to the 
template engine.


Modified: django/trunk/django/utils/timezone.py
===
--- django/trunk/django/utils/timezone.py   2012-03-03 19:02:49 UTC (rev 
17641)
+++ django/trunk/django/utils/timezone.py   2012-03-03 19:57:25 UTC (rev 
17642)
@@ -17,7 +17,7 @@
 __all__ = [
 'utc', 'get_default_timezone', 'get_current_timezone',
 'activate', 'deactivate', 'override',
-'localtime', 'is_naive', 'is_aware', 'make_aware', 'make_naive',
+'is_naive', 'is_aware', 'make_aware', 'make_naive',
 ]
 
 
@@ -204,7 +204,7 @@
 del _active.value
 
 
-# Utilities
+# Templates
 
 def localtime(value, use_tz=None):
 """
@@ -212,6 +212,8 @@
 
 If use_tz is provided and is not None, that will force the value to
 be converted (or not), overriding the value of settings.USE_TZ.
+
+This function is designed for use by the template engine.
 """
 if (isinstance(value, datetime)
 and (settings.USE_TZ if use_tz is None else use_tz)
@@ -224,6 +226,9 @@
 value = timezone.normalize(value)
 return value
 
+
+# Utilities
+
 def now():
 """
 Returns an aware or naive datetime.datetime, depending on settings.USE_TZ.

Modified: django/trunk/docs/ref/utils.txt
===
--- django/trunk/docs/ref/utils.txt 2012-03-03 19:02:49 UTC (rev 17641)
+++ django/trunk/docs/ref/utils.txt 2012-03-03 19:57:25 UTC (rev 17642)
@@ -666,11 +666,6 @@
 ``None``, the :ref:`current time zone ` is unset
 on entry with :func:`deactivate()` instead.
 
-.. function:: localtime(value, use_tz=None)
-
-This function is used by the template engine to convert datetimes to local
-time where appropriate.
-
 .. function:: now()
 
 Returns an aware or naive :class:`~datetime.datetime` that represents the

-- 
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] #17605: It is not documented how to work with ManyToMany relations

[Django]

#17605: It is not documented how to work with ManyToMany relations
-+
 Reporter:  kmike|Owner:  ramiro
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by ramiro):

 * needs_better_patch:  1 => 0


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

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

[Changeset] r17641 - in django/trunk: django/db/models tests/modeltests/many_to_one

[noreply]

Author: jezdez
Date: 2012-03-03 11:02:49 -0800 (Sat, 03 Mar 2012)
New Revision: 17641

Modified:
   django/trunk/django/db/models/base.py
   django/trunk/tests/modeltests/many_to_one/tests.py
Log:
Fixed #10498 -- Fixed using ugettext_lazy values when creating model instances. 
Thanks to Claude Paroz and Jonas Obrist.

Modified: django/trunk/django/db/models/base.py
===
--- django/trunk/django/db/models/base.py   2012-03-03 17:50:18 UTC (rev 
17640)
+++ django/trunk/django/db/models/base.py   2012-03-03 19:02:49 UTC (rev 
17641)
@@ -20,7 +20,7 @@
 from django.db.models import signals
 from django.db.models.loading import register_models, get_model
 from django.utils.translation import ugettext_lazy as _
-from django.utils.functional import curry
+from django.utils.functional import curry, Promise
 from django.utils.encoding import smart_str, force_unicode
 from django.utils.text import get_text_list, capfirst
 
@@ -297,10 +297,14 @@
 # is *not* consumed. We rely on this, so don't change the order
 # without changing the logic.
 for val, field in izip(args, fields_iter):
+if isinstance(val, Promise):
+val = force_unicode(val)
 setattr(self, field.attname, val)
 else:
 # Slower, kwargs-ready version.
 for val, field in izip(args, fields_iter):
+if isinstance(val, Promise):
+val = force_unicode(val)
 setattr(self, field.attname, val)
 kwargs.pop(field.name, None)
 # Maintain compatibility with existing calls.
@@ -354,6 +358,8 @@
 # checked) by the RelatedObjectDescriptor.
 setattr(self, field.name, rel_obj)
 else:
+if isinstance(val, Promise):
+val = force_unicode(val)
 setattr(self, field.attname, val)
 
 if kwargs:

Modified: django/trunk/tests/modeltests/many_to_one/tests.py
===
--- django/trunk/tests/modeltests/many_to_one/tests.py  2012-03-03 17:50:18 UTC 
(rev 17640)
+++ django/trunk/tests/modeltests/many_to_one/tests.py  2012-03-03 19:02:49 UTC 
(rev 17641)
@@ -5,6 +5,7 @@
 
 from django.core.exceptions import MultipleObjectsReturned
 from django.test import TestCase
+from django.utils.translation import ugettext_lazy
 
 from .models import Article, Reporter
 
@@ -412,3 +413,14 @@
 
 # Same as each other
 self.assertTrue(r1.article_set.__class__ is r2.article_set.__class__)
+
+def test_create_relation_with_ugettext_lazy(self):
+reporter = Reporter.objects.create(first_name='John',
+   last_name='Smith',
+   email='john.sm...@example.com')
+lazy = ugettext_lazy(u'test')
+reporter.article_set.create(headline=lazy,
+pub_date=datetime(2011, 6, 10))
+notlazy = unicode(lazy)
+article = reporter.article_set.get()
+self.assertEqual(article.headline, notlazy)

-- 
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] #10498: Passing ugettext_lazy to related object's create() doesn't work

[Django]

#10498: Passing ugettext_lazy to related object's create() doesn't work
-+-
 Reporter:  mtredinnick  |Owner:  ojii
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  dceu2011 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jezdez):

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


Comment:

 In [17641]:
 {{{
 #!CommitTicketReference repository="" revision="17641"
 Fixed #10498 -- Fixed using ugettext_lazy values when creating model
 instances. Thanks to Claude Paroz and Jonas Obrist.
 }}}

-- 
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] #17822: Update base translations and push to Transifex

[Django]

#17822: Update base translations and push to Transifex
-+-
   Reporter:  jezdez |  Owner:  jezdez
   Type: | Status:  new
  Cleanup/optimization   |Version:  1.4-beta-1
  Component: |   Keywords:
  Translations   |  Has patch:  0
   Severity:  Release|Needs tests:  0
  blocker|  Easy pickings:  0
   Triage Stage:  Accepted   |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-


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

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

[Django] #17821: Extra fields on many-to-many relationships

[Django]

#17821: Extra fields on many-to-many relationships
-+-
 Reporter:  jedlau@… |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:   |Version:  SVN
  Documentation  |   Keywords:  many-to-many intermediate model
 Severity:  Normal   |  Has patch:  0
 Triage Stage:  Unreviewed   |  UI/UX:  0
Easy pickings:  1|
-+-
 '''Existing text'''
 {{{
 As you are using an intermediate model, you can also query on its
 attributes:

 # Find all the members of the Beatles that joined after 1 Jan 1961
 >>> Person.objects.filter(
 ... group__name='The Beatles',
 ... membership__date_joined__gt=date(1961,1,1))
 [>> Person.objects.filter(
 ... membership__group__name='The Beatles',
 ... membership__date_joined__gt=date(1961,1,1))
 [https://code.djangoproject.com/ticket/17821>
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] #15636: django.contrib.staticfiles - "collectstatic" makes all files names lowercase.

[Django]

#15636: django.contrib.staticfiles - "collectstatic" makes all files names
lowercase.
-+-
 Reporter:  drakaar  |Owner:  jezdez
 Type:  Uncategorized|   Status:  closed
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by anonymous):

 Replying to [comment:9 jezdez]:
 > I can't reproduce this on Windows 7, so please provide a test case that
 shows the issue. Also, which version of Windows did you use, a case
 insensitive filesystem, which Python, which version of Django?
 My environment: Windows Vista Home Basic SP2 32 bit, Python 2.7.2, Django
 1.3.1. All the file names are changed to lowercase after I run
 collectstatic.

-- 
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] #17717: django.core.serializers.serialize doesn't deal with proxy models

[Django]

#17717: django.core.serializers.serialize doesn't deal with proxy models
-+-
 Reporter:  lakin|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core |  Version:  1.1
  (Serialization)|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jezdez):

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


Comment:

 In [17640]:
 {{{
 #!CommitTicketReference repository="" revision="17640"
 Fixed #17717 -- Fixed serialization of proxy models. Thanks, Anssi
 Kääriäinen.
 }}}

-- 
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] r17640 - in django/trunk: django/core/serializers tests/regressiontests/serializers_regress

[noreply]

Author: jezdez
Date: 2012-03-03 09:50:18 -0800 (Sat, 03 Mar 2012)
New Revision: 17640

Modified:
   django/trunk/django/core/serializers/base.py
   django/trunk/tests/regressiontests/serializers_regress/models.py
   django/trunk/tests/regressiontests/serializers_regress/tests.py
Log:
Fixed #17717 -- Fixed serialization of proxy models. Thanks, Anssi 
K?\195?\164?\195?\164ri?\195?\164inen.

Modified: django/trunk/django/core/serializers/base.py
===
--- django/trunk/django/core/serializers/base.py2012-03-03 17:41:32 UTC 
(rev 17639)
+++ django/trunk/django/core/serializers/base.py2012-03-03 17:50:18 UTC 
(rev 17640)
@@ -41,7 +41,10 @@
 self.start_serialization()
 for obj in queryset:
 self.start_object(obj)
-for field in obj._meta.local_fields:
+# Use the concrete parent class' _meta instead of the object's 
_meta
+# This is to avoid local_fields problems for proxy models. Refs 
#17717.
+concrete_class = obj._meta.proxy_for_model or obj.__class__
+for field in concrete_class._meta.local_fields:
 if field.serialize:
 if field.rel is None:
 if self.selected_fields is None or field.attname in 
self.selected_fields:
@@ -49,7 +52,7 @@
 else:
 if self.selected_fields is None or field.attname[:-3] 
in self.selected_fields:
 self.handle_fk_field(obj, field)
-for field in obj._meta.many_to_many:
+for field in concrete_class._meta.many_to_many:
 if field.serialize:
 if self.selected_fields is None or field.attname in 
self.selected_fields:
 self.handle_m2m_field(obj, field)

Modified: django/trunk/tests/regressiontests/serializers_regress/models.py
===
--- django/trunk/tests/regressiontests/serializers_regress/models.py
2012-03-03 17:41:32 UTC (rev 17639)
+++ django/trunk/tests/regressiontests/serializers_regress/models.py
2012-03-03 17:50:18 UTC (rev 17640)
@@ -259,6 +259,10 @@
 parent = models.OneToOneField(BaseModel)
 child_data = models.IntegerField()
 
+class ProxyBaseModel(BaseModel):
+class Meta:
+proxy = True
+
 class LengthModel(models.Model):
 data = models.IntegerField()
 

Modified: django/trunk/tests/regressiontests/serializers_regress/tests.py
===
--- django/trunk/tests/regressiontests/serializers_regress/tests.py 
2012-03-03 17:41:32 UTC (rev 17639)
+++ django/trunk/tests/regressiontests/serializers_regress/tests.py 
2012-03-03 17:50:18 UTC (rev 17640)
@@ -40,9 +40,9 @@
 DecimalPKData, FloatPKData, IntegerPKData, IPAddressPKData,
 GenericIPAddressPKData, PhonePKData, PositiveIntegerPKData,
 PositiveSmallIntegerPKData, SlugPKData, SmallPKData, USStatePKData,
-AutoNowDateTimeData, ModifyingSaveData, InheritAbstractModel,
-ExplicitInheritBaseModel, InheritBaseModel, BigIntegerData, LengthModel,
-Tag, ComplexModel)
+AutoNowDateTimeData, ModifyingSaveData, InheritAbstractModel, BaseModel,
+ExplicitInheritBaseModel, InheritBaseModel, ProxyBaseModel, BigIntegerData,
+LengthModel, Tag, ComplexModel)
 
 # A set of functions that can be used to recreate
 # test data objects of various kinds.
@@ -408,7 +408,15 @@
 for obj in serializers.deserialize("yaml", "{"):
 pass
 
+def test_serialize_proxy_model(self):
+BaseModel.objects.create(parent_data=1)
+base_objects  = BaseModel.objects.all()
+proxy_objects = ProxyBaseModel.objects.all()
+base_data  = serializers.serialize("json", base_objects)
+proxy_data = serializers.serialize("json", proxy_objects)
+self.assertEqual(base_data, proxy_data.replace('proxy', ''))
 
+
 def serializerTest(format, self):
 
 # Create all the objects defined in the test data

-- 
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] r17639 - django/trunk/tests/regressiontests/introspection

[noreply]

Author: aaugustin
Date: 2012-03-03 09:41:32 -0800 (Sat, 03 Mar 2012)
New Revision: 17639

Modified:
   django/trunk/tests/regressiontests/introspection/tests.py
Log:
Fixed a typo in r17638.


Modified: django/trunk/tests/regressiontests/introspection/tests.py
===
--- django/trunk/tests/regressiontests/introspection/tests.py   2012-03-03 
17:16:43 UTC (rev 17638)
+++ django/trunk/tests/regressiontests/introspection/tests.py   2012-03-03 
17:41:32 UTC (rev 17639)
@@ -91,7 +91,7 @@
 
 # Oracle forces null=True under the hood in some cases (see
 # 
https://docs.djangoproject.com/en/dev/ref/databases/#null-and-empty-strings)
-# so its idea about null_ok in cursor.drescription is different from ours
+# so its idea about null_ok in cursor.description is different from ours.
 @skipIfDBFeature('interprets_empty_strings_as_nulls')
 def test_get_table_description_nullable(self):
 cursor = connection.cursor()

-- 
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] r17638 - django/trunk/tests/regressiontests/introspection

[noreply]

Author: ramiro
Date: 2012-03-03 09:16:43 -0800 (Sat, 03 Mar 2012)
New Revision: 17638

Modified:
   django/trunk/tests/regressiontests/introspection/tests.py
Log:
Modified a test added in r17508 to not run under Oracle.

Modified: django/trunk/tests/regressiontests/introspection/tests.py
===
--- django/trunk/tests/regressiontests/introspection/tests.py   2012-03-03 
10:13:35 UTC (rev 17637)
+++ django/trunk/tests/regressiontests/introspection/tests.py   2012-03-03 
17:16:43 UTC (rev 17638)
@@ -3,7 +3,7 @@
 from functools import update_wrapper
 
 from django.db import connection
-from django.test import TestCase, skipUnlessDBFeature
+from django.test import TestCase, skipUnlessDBFeature, skipIfDBFeature
 
 from .models import Reporter, Article
 
@@ -89,6 +89,10 @@
 ['IntegerField', 'CharField', 'CharField', 'CharField', 
'BigIntegerField']
 )
 
+# Oracle forces null=True under the hood in some cases (see
+# 
https://docs.djangoproject.com/en/dev/ref/databases/#null-and-empty-strings)
+# so its idea about null_ok in cursor.drescription is different from ours
+@skipIfDBFeature('interprets_empty_strings_as_nulls')
 def test_get_table_description_nullable(self):
 cursor = connection.cursor()
 desc = connection.introspection.get_table_description(cursor, 
Reporter._meta.db_table)

-- 
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] #17820: A few more places where duplicated handling of mgmt command options default values happens

[Django]

#17820: A few more places where duplicated handling of mgmt command options 
default
values happens
-+-
 Reporter:  ramiro   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * stage:  Unreviewed => 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] #17820: A few more places where duplicated handling of mgmt command options default values happens

[Django]

#17820: A few more places where duplicated handling of mgmt command options 
default
values happens
-+-
 Reporter:  ramiro   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Description changed by ramiro:

Old description:

> See #13760, #100080 and #17799.

New description:

 See #13760, #10080 and #17799.

--

-- 
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] #17820: A few more places where duplicated handling of mgmt command options default values happens

[Django]

#17820: A few more places where duplicated handling of mgmt command options 
default
values happens
-+-
   Reporter:  ramiro |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |Version:  SVN
  Component:  Core   |   Keywords:
  (Management commands)  |  Has patch:  1
   Severity:  Normal |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 See #13760, #100080 and #17799.

-- 
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] #14861: Importing settings in a module that contains a logging Handler causes circular import.

[Django]

#14861: Importing settings in a module that contains a logging Handler causes
circular import.
---+
 Reporter:  donspaulding   |Owner:  nobody
 Type:  Uncategorized  |   Status:  reopened
Component:  Core (Other)   |  Version:  SVN
 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
---+
Changes (by claudep):

 * component:  Documentation => Core (Other)


-- 
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] #17627: contrib.admin.util is misnamed

[Django]

#17627: contrib.admin.util is misnamed
--+
 Reporter:  PaulM |Owner:  lukegb
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.admin |  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:  0
--+

Comment (by lukegb):

 Replying to [comment:15 russellm]:
 > On a related note -- if you want to make this a really sweet target for
 commit, you could also address the other instances of util.py in the
 source tree.

 Done in the latest version (0002.patch) of my patch.

 Side notes which break backwards compatibility:
 Code which does
 {{{#!python
 from django.db import utils
 from django.db.backends import *
 }}}
 will break with this change, as django.db.backends.utils will overwrite
 django.db.utils. Not sure how to fix this, but I fixed it in the instances
 where Django does it:
 * django/db/backends/mysql/base.py
 * django/db/backends/oracle/base.py
 * django/db/backends/postgresql_psycopg2/base.py
 * django/db/backends/sqlite3/base.py

 (just realised I forgot to update the deprecation notes - new patch
 incoming)

-- 
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] #16233: Add definition of db_alias in Performing raw SQL queries

[Django]

#16233: Add definition of db_alias in Performing raw SQL queries
--+
 Reporter:  charlax   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by claudep):

 * has_patch:  0 => 1


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

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

Re: [Django] #17816: UnicodeEncodeError in Image- and FileFields

[Django]

#17816: UnicodeEncodeError in Image- and FileFields
-+-
 Reporter:  andi@…   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Forms|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by andi@…):

 The answers to your questions:
 Ubuntu 10.04
 Python 2.6.5
 Django 1.3.1
 Deployment with mod_wsgi

-- 
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] #9112: New releases do not reliably overwrite old ones

[Django]

#9112: New releases do not reliably overwrite old ones
-+-
 Reporter:  holdenweb|Owner:  packagers
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  release engineering  | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * owner:  aaugustin => packagers
 * 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.

[Changeset] r17637 - django/trunk/docs/topics/i18n

[noreply]

Author: aaugustin
Date: 2012-03-03 02:13:35 -0800 (Sat, 03 Mar 2012)
New Revision: 17637

Modified:
   django/trunk/docs/topics/i18n/timezones.txt
Log:
Fixed #17808 -- Explained why fixtures can trigger RuntimeWarnings after 
enabling time zone support, and how to fix them.


Modified: django/trunk/docs/topics/i18n/timezones.txt
===
--- django/trunk/docs/topics/i18n/timezones.txt 2012-03-03 09:11:54 UTC (rev 
17636)
+++ django/trunk/docs/topics/i18n/timezones.txt 2012-03-03 10:13:35 UTC (rev 
17637)
@@ -380,8 +380,8 @@
 Here's how to migrate a project that was started before Django supported time
 zones.
 
-Data
-
+Database
+
 
 PostgreSQL
 ~~
@@ -428,15 +428,42 @@
 :func:`~django.utils.timezone.make_naive`.
 
 Finally, in order to help you locate code that needs upgrading, Django raises
-a warning when you attempt to save a naive datetime to the database. During
-development, you can turn such warnings into exceptions and get a traceback
-by adding the following to your settings file::
+a warning when you attempt to save a naive datetime to the database::
 
+RuntimeWarning: DateTimeField received a naive datetime (2012-01-01 
00:00:00) while time zone support is active.
+
+During development, you can turn such warnings into exceptions and get a
+traceback by adding the following to your settings file::
+
 import warnings
 warnings.filterwarnings(
 'error', r"DateTimeField received a naive datetime",
 RuntimeWarning, r'django\.db\.models\.fields')
 
+Fixtures
+
+
+When serializing an aware datetime, the UTC offset is included, like this::
+
+"2011-09-01T13:20:30+03:00"
+
+For a naive datetime, it obviously isn't::
+
+"2011-09-01T13:20:30"
+
+For models with :class:`~django.db.models.DateTimeField`\ s, this difference
+makes it impossible to write a fixture that works both with and without time
+zone support.
+
+Fixtures generated with ``USE_TZ = False``, or before Django 1.4, use the
+"naive" format. If your project contains such fixtures, after you enable time
+zone support, you'll see :exc:`RuntimeWarning`\ s when you load them. To get
+rid of the warnings, you must convert your fixtures to the "aware" format.
+
+You can regenerate fixtures with :djadmin:`loaddata` then :djadmin:`dumpdata`.
+Or, if they're small enough, you can simply edit them to add the UTC offset
+that matches your :setting:`TIME_ZONE` to each serialized datetime.
+
 .. _pytz: http://pytz.sourceforge.net/
 .. _these issues: http://pytz.sourceforge.net/#problems-with-localtime
 .. _tz database: http://en.wikipedia.org/wiki/Tz_database

-- 
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] #17808: Improve the warning when fixtures containing naive datetimes are loaded with USE_TZ = True

[Django]

#17808: Improve the warning when fixtures containing naive datetimes are loaded
with USE_TZ = True
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:
Component:  Documentation|  1.4-beta-1
 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 [17637]:
 {{{
 #!CommitTicketReference repository="" revision="17637"
 Fixed #17808 -- Explained why fixtures can trigger RuntimeWarnings after
 enabling time zone support, and how to fix them.
 }}}

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

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

Re: [Django] #17193: Send templated email.

[Django]

#17193: Send templated email.
-+-
 Reporter:  tomchristie  |Owner:
 Type:  New feature  |  julianapplebaum
Component:  Core (Mail)  |   Status:  assigned
 Severity:  Normal   |  Version:
 Keywords:   |   Resolution:
Has patch:  1| Triage Stage:  Design
  Needs tests:  0|  decision needed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by artem.rizhov@…):

 Ooops..[[BR]]
 {{{s/Actuall, for me it //}}}[[BR]]
 Sorry for trash in the message.

-- 
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] #17193: Send templated email.

[Django]

#17193: Send templated email.
-+-
 Reporter:  tomchristie  |Owner:
 Type:  New feature  |  julianapplebaum
Component:  Core (Mail)  |   Status:  assigned
 Severity:  Normal   |  Version:
 Keywords:   |   Resolution:
Has patch:  1| Triage Stage:  Design
  Needs tests:  0|  decision needed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by artem.rizhov@…):

 * cc: artem.rizhov@… (added)


Comment:

 Hi there!

 Replying to [comment:15 julien]:
 > I do agree that creating html+plain emails is still a little too hard in
 Django, but in my opinion this could be simplified by introducing a new
 helper class wrapping around `EmailMultiAlternatives` and providing a
 simpler API and sensible defaults. For example, something like:
 `HTMLEmailMessage(body_plain='...', body_html='...')`

 My implementation is based on `EmailMultiAlternatives` :) It's available
 at !GitHub https://github.com/artemrizhov/django-mail-templated

 Actuall, for me it
 I've emailed to django-developers mailing list and proposed to merge it
 into Django. However my proposition was declined.
 http://groups.google.com/group/django-
 developers/browse_frm/thread/4728f20dd8023dd9

 I'd be glad to continue work on it, but there is no any reason to polish
 it more for a while. :( At least unless I need some additional
 functionality, or some activity is registered on the github project. :)
 Propositions and suggestions are welcome.

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

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

Re: [Django] #17808: Improve the warning when fixtures containing naive datetimes are loaded with USE_TZ = True

[Django]

#17808: Improve the warning when fixtures containing naive datetimes are loaded
with USE_TZ = True
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Documentation|  1.4-beta-1
 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):

 This warning is emitted at the database layer. I can't provide a more
 specific error message in the serialization layer without breaking its
 architecture.

 I'm going to add a note in the "Migration guide" of the time zone docs,
 and maybe also in the upcoming FAQ (#17738).

-- 
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] #17808: Improve the warning when fixtures containing naive datetimes are loaded with USE_TZ = True

[Django]

#17808: Improve the warning when fixtures containing naive datetimes are loaded
with USE_TZ = True
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Documentation|  1.4-beta-1
 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
-+-
Description changed by aaugustin:

Old description:

> As discussed on -developers.

New description:

 As discussed [http://groups.google.com/group/django-
 developers/browse_thread/thread/c1639272808e5612 on django-developers].

--

-- 
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] r17636 - in django/trunk/docs: . howto/deployment/wsgi internals/contributing intro ref/contrib/gis topics

[noreply]

Author: aaugustin
Date: 2012-03-03 01:11:54 -0800 (Sat, 03 Mar 2012)
New Revision: 17636

Modified:
   django/trunk/docs/README
   django/trunk/docs/howto/deployment/wsgi/gunicorn.txt
   django/trunk/docs/howto/deployment/wsgi/uwsgi.txt
   django/trunk/docs/internals/contributing/writing-documentation.txt
   django/trunk/docs/intro/whatsnext.txt
   django/trunk/docs/ref/contrib/gis/install.txt
   django/trunk/docs/topics/auth.txt
   django/trunk/docs/topics/install.txt
Log:
Fixed #9995 -- Updated the installation instructions to recommend pip. Also 
fixed ReST errors. Refs #9112.


Modified: django/trunk/docs/README
===
--- django/trunk/docs/README2012-03-03 02:13:35 UTC (rev 17635)
+++ django/trunk/docs/README2012-03-03 09:11:54 UTC (rev 17636)
@@ -5,9 +5,9 @@
 documentation system [2].  This allows it to be built into other forms for
 easier viewing and browsing.
 
-To create an HTML version of the docs on a Unix machine (Linux or Mac):
+To create an HTML version of the docs:
 
-* Install Sphinx (using ``easy_install Sphinx`` or some other method)
+* Install Sphinx (using ``sudo pip install Sphinx`` or some other method)
 
 * In this docs/ directory, type ``make html`` (or ``make.bat html`` on
   Windows) at a shell prompt.

Modified: django/trunk/docs/howto/deployment/wsgi/gunicorn.txt
===
--- django/trunk/docs/howto/deployment/wsgi/gunicorn.txt2012-03-03 
02:13:35 UTC (rev 17635)
+++ django/trunk/docs/howto/deployment/wsgi/gunicorn.txt2012-03-03 
09:11:54 UTC (rev 17636)
@@ -18,8 +18,8 @@
 Installing Gunicorn
 ===
 
-Installing gunicorn is as easy as ``pip install gunicorn``. For more details,
-see the `gunicorn documentation`_.
+Installing gunicorn is as easy as ``sudo pip install gunicorn``. For more
+details, see the `gunicorn documentation`_.
 
 .. _gunicorn documentation: http://gunicorn.org/install.html
 

Modified: django/trunk/docs/howto/deployment/wsgi/uwsgi.txt
===
--- django/trunk/docs/howto/deployment/wsgi/uwsgi.txt   2012-03-03 02:13:35 UTC 
(rev 17635)
+++ django/trunk/docs/howto/deployment/wsgi/uwsgi.txt   2012-03-03 09:11:54 UTC 
(rev 17636)
@@ -14,13 +14,15 @@
 
 The uWSGI wiki describes several `installation procedures`_. Using pip, the
 Python package manager, you can install any uWSGI version with a single
-command. For example::
+command. For example:
 
+.. code-block:: bash
+
 # Install current stable version.
-pip install uwsgi
+$ sudo pip install uwsgi
 
 # Or install LTS (long term support).
-pip install http://projects.unbit.it/downloads/uwsgi-lts.tar.gz
+$ sudo pip install http://projects.unbit.it/downloads/uwsgi-lts.tar.gz
 
 .. _installation procedures: http://projects.unbit.it/uwsgi/wiki/Install
 

Modified: django/trunk/docs/internals/contributing/writing-documentation.txt
===
--- django/trunk/docs/internals/contributing/writing-documentation.txt  
2012-03-03 02:13:35 UTC (rev 17635)
+++ django/trunk/docs/internals/contributing/writing-documentation.txt  
2012-03-03 09:11:54 UTC (rev 17636)
@@ -29,7 +29,7 @@
 __ http://docutils.sourceforge.net/
 
 To actually build the documentation locally, you'll currently need to install
-Sphinx -- ``easy_install Sphinx`` should do the trick.
+Sphinx -- ``sudo pip install Sphinx`` should do the trick.
 
 .. note::
 

Modified: django/trunk/docs/intro/whatsnext.txt
===
--- django/trunk/docs/intro/whatsnext.txt   2012-03-03 02:13:35 UTC (rev 
17635)
+++ django/trunk/docs/intro/whatsnext.txt   2012-03-03 09:11:54 UTC (rev 
17636)
@@ -166,12 +166,11 @@
 
 * Django's documentation uses a system called Sphinx__ to convert from
   plain text to HTML. You'll need to install Sphinx by either downloading
-  and installing the package from the Sphinx Web site, or by Python's
-  ``easy_install``:
+  and installing the package from the Sphinx Web site, or with ``pip``:
 
   .. code-block:: bash
 
-$ easy_install Sphinx
+$ sudo pip install Sphinx
 
 * Then, just use the included ``Makefile`` to turn the documentation into
   HTML:

Modified: django/trunk/docs/ref/contrib/gis/install.txt
===
--- django/trunk/docs/ref/contrib/gis/install.txt   2012-03-03 02:13:35 UTC 
(rev 17635)
+++ django/trunk/docs/ref/contrib/gis/install.txt   2012-03-03 09:11:54 UTC 
(rev 17636)
@@ -40,8 +40,10 @@
 -
 
 Because GeoDjango is included with Django, please refer to Django's
-:doc:`installation instructions ` for details on how to 
install.
+:ref:`installation instructions ` for details on
+how to install.
 
+
 .. _spatial_database:
 
 Spatial database
@@ -837,14 +839,13 @@
 After 

Re: [Django] #9995: Mention 'pip install Django' as an alternative installation method.

[Django]

#9995: Mention 'pip install Django' as an alternative installation method.
-+-
 Reporter:  daveyjoe |Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.0
Component:  Documentation|   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  easy_install, docs,  |  Needs documentation:  0
  documentation, install,|  Patch needs improvement:  1
  installation, setup|UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 In [17636]:
 {{{
 #!CommitTicketReference repository="" revision="17636"
 Fixed #9995 -- Updated the installation instructions to recommend pip.
 Also fixed ReST errors. Refs #9112.
 }}}

-- 
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] #9112: New releases do not reliably overwrite old ones

[Django]

#9112: New releases do not reliably overwrite old ones
-+-
 Reporter:  holdenweb|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  release engineering  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 In [17636]:
 {{{
 #!CommitTicketReference repository="" revision="17636"
 Fixed #9995 -- Updated the installation instructions to recommend pip.
 Also fixed ReST errors. Refs #9112.
 }}}

-- 
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] #9112: New releases do not reliably overwrite old ones

[Django]

#9112: New releases do not reliably overwrite old ones
-+-
 Reporter:  holdenweb|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  release engineering  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 To clarify: my previous comment means that this ticket is only about
 "touch the files before packaging them to reset the date".

-- 
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] #17814: RELATED_NAME_OVERRIDES

[Django]

#17814: RELATED_NAME_OVERRIDES
-+-
 Reporter:  yanchenko.igor@… |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 possible settings are not the best place for this, but this is the most
 obvious place, if I meet the discrepancy with the code model, I would like
 to find it in the settings, but not in another application.

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