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

 OK, so it seems safe to say Oracle doesn't suffer from this. You need 64K
 of SQL string without the parameters, and that will fit a lot of
 placeholders. I checked DB2 and `SqlServer` and they seems to be safe
 enough from this issue, too.

 So, it seems the only problematic backend is SQLite with its 1000
 parameters limit. Fixing bulk_create is not that hard, but I have no idea
 how hard it is to fix delete. If delete is hard, is it worth fixing
 bulk_create alone? If both are somewhat easy then I think this should be
 done. It will make testing a little bit easier. If this is fixed, there is
 at least one 2500 object creating test in queries which should be fixed,
 too. Makes the test runner a few seconds faster.

-- 
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] #13163: Display link to change-form on inlines where model is registered in admin site

[Django]

#13163: Display link to change-form on inlines where model is registered in 
admin
site
---+
 Reporter:  DrMeers|Owner:  DrMeers
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords:  inline link| Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  1
---+

Comment (by anonymous):

 still waiting for this to become a feature.

-- 
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 streeter):

 * cc: streeter (added)


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

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

Re: [Django] #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 alpar):

 Replying to [comment:7 carljm]:
 > [...] since it seems likely that the answer "use a better database"
 suffices to prevent it being an actual problem in production [...]

 My problem is that although we "use a better database" for production, but
 we use SQLite during the development, because it is easier to setup, to
 create and share snapshots etc.
 I believe we are not alone with this development model.

 If we accept that "correct behavior" should have priority over
 "performance", then SQLite, `bulk_create()` may simply create the object
 one-by-one. It is slow (on SQLite), but at least it works, and one may
 hope better performance on a "better database". So, it is already much
 better than having something unusable.

 How does the batch size affects to performance? As far as I understand,
 there is an inevitable processing requirement for inserting data, plus the
 overhead of processing the SQL query (one-by-one). The feature
 `bulk_create()` is about to reduce the second one. Thus, if we use batch
 size as small as 10, then it already reduces the overhead to one tenth.
 Although I didn't tested it, but it makes me feel, that ''the performance
 gain can already be achieved using very small batches'', Large batches
 will result in negligible further improvements.

 Finally, using reasonable sized batches may be beneficial even on "better
 databases", as a huge single SQL insert command may cause problems (such
 as timeout) on heavily loaded systems.

-- 
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 carljm):

 There is already a `supports_1000_query_parameters` db backend feature,
 set to `False` for SQLite and `True` for all other backends. That seems
 kind of odd, like it should be `max_query_parameters = 1000` instead, but
 it was probably done that way so it could be used with
 `skipUnlessDBFeature` in the tests, which is the only place its currently
 used.

 Whether we leave that feature as it is or change it to a number, it could
 be used to resolve both this and #16426. Though if SQLite is really the
 only affected backend, it's awfully tempting to just say "get a better
 database" rather than introducing a bunch of extra chunking complexity in
 both deletion and bulk insertion, just for SQLite's sake.

-- 
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 anonymous):

 I just ran Aymeric test inserting 10K !SomeModel instances settings values
 of its ''f'' field to both a 30-char string and 300-char string without
 failures. Database is Oracle Database 10g Express Universal Edition
 10.2.0.1 as per OracleTestSetup

-- 
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] r17635 - in django/trunk: django/contrib/admin/views tests/regressiontests/admin_changelist tests/regressiontests/admin_views

[noreply]

Author: julien
Date: 2012-03-02 18:13:35 -0800 (Fri, 02 Mar 2012)
New Revision: 17635

Modified:
   django/trunk/django/contrib/admin/views/main.py
   django/trunk/tests/regressiontests/admin_changelist/models.py
   django/trunk/tests/regressiontests/admin_changelist/tests.py
   django/trunk/tests/regressiontests/admin_views/admin.py
   django/trunk/tests/regressiontests/admin_views/models.py
   django/trunk/tests/regressiontests/admin_views/tests.py
Log:
Fixed #17198 -- Ensured that a deterministic order is used across all database 
backends for displaying the admin change list's results. Many thanks to Luke 
Plant for the report and general approach, to everyone involved in the design 
discussions, and to Carl Meyer for the patch review. Refs #16819.

Modified: django/trunk/django/contrib/admin/views/main.py
===
--- django/trunk/django/contrib/admin/views/main.py 2012-03-03 01:06:37 UTC 
(rev 17634)
+++ django/trunk/django/contrib/admin/views/main.py 2012-03-03 02:13:35 UTC 
(rev 17635)
@@ -66,7 +66,6 @@
 self.list_editable = ()
 else:
 self.list_editable = list_editable
-self.ordering = self.get_ordering(request)
 self.query = request.GET.get(SEARCH_VAR, '')
 self.query_set = self.get_query_set(request)
 self.get_results(request)
@@ -218,13 +217,18 @@
 attr = getattr(self.model, field_name)
 return getattr(attr, 'admin_order_field', None)
 
-def get_ordering(self, request):
+def get_ordering(self, request, queryset):
+"""
+Returns the list of ordering fields for the change list.
+First we check the get_ordering() method in model admin, then we check
+the object's default ordering. Then, any manually-specified ordering
+from the query string overrides anything. Finally, a deterministic
+order is guaranteed by ensuring the primary key is used as the last
+ordering field.
+"""
 params = self.params
-# For ordering, first check the if exists the "get_ordering" method
-# in model admin, then check "ordering" parameter in the admin
-# options, then check the object's default ordering. Finally, a
-# manually-specified ordering from the query string overrides anything.
-ordering = self.model_admin.get_ordering(request) or 
self._get_default_ordering()
+ordering = list(self.model_admin.get_ordering(request)
+or self._get_default_ordering())
 if ORDER_VAR in params:
 # Clear ordering and used params
 ordering = []
@@ -239,6 +243,19 @@
 ordering.append(pfx + order_field)
 except (IndexError, ValueError):
 continue # Invalid ordering specified, skip it.
+
+# Add the given query's ordering fields, if any.
+ordering.extend(queryset.query.order_by)
+
+# Ensure that the primary key is systematically present in the list of
+# ordering fields so we can guarantee a deterministic order across all
+# database backends.
+pk_name = self.lookup_opts.pk.name
+if not (set(ordering) & set(['pk', '-pk', pk_name, '-' + pk_name])):
+# The two sets do not intersect, meaning the pk isn't present. So
+# we add it.
+ordering.append('pk')
+
 return ordering
 
 def get_ordering_field_columns(self):
@@ -322,8 +339,8 @@
 break
 
 # Set ordering.
-if self.ordering:
-qs = qs.order_by(*self.ordering)
+ordering = self.get_ordering(request, qs)
+qs = qs.order_by(*ordering)
 
 # Apply keyword searches.
 def construct_search(field_name):

Modified: django/trunk/tests/regressiontests/admin_changelist/models.py
===
--- django/trunk/tests/regressiontests/admin_changelist/models.py   
2012-03-03 01:06:37 UTC (rev 17634)
+++ django/trunk/tests/regressiontests/admin_changelist/models.py   
2012-03-03 02:13:35 UTC (rev 17635)
@@ -57,3 +57,27 @@
 
 class Meta:
 ordering = ('speed', 'load')
+
+
+class UnorderedObject(models.Model):
+"""
+Model without any defined `Meta.ordering`.
+Refs #17198.
+"""
+bool = models.BooleanField(default=True)
+
+
+class OrderedObjectManager(models.Manager):
+def get_query_set(self):
+return super(OrderedObjectManager, 
self).get_query_set().order_by('-number')
+
+class OrderedObject(models.Model):
+"""
+Model with Manager that defines a default order.
+Refs #17198.
+"""
+name = models.CharField(max_length=255)
+bool = models.BooleanField(default=True)
+number = models.IntegerField(default=0)
+
+objects = OrderedObjectManager()
\ No newline at end of file

Modified: 

Re: [Django] #16819: list_editable breaks multipage changelists

[Django]

#16819: list_editable breaks multipage changelists
-+-
 Reporter:  anossov@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  SVN
 Severity:  Release blocker  |   Resolution:  duplicate
 Keywords:  admin list_editable  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by julien):

 In [17635]:
 {{{
 #!CommitTicketReference repository="" revision="17635"
 Fixed #17198 -- Ensured that a deterministic order is used across all
 database backends for displaying the admin change list's results. Many
 thanks to Luke Plant for the report and general approach, to everyone
 involved in the design discussions, and to Carl Meyer for the patch
 review. Refs #16819.
 }}}

-- 
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] #17198: In admin results can be omitted due to pagination and inadequate ordering clauses

[Django]

#17198: In admin results can be omitted due to pagination and inadequate 
ordering
clauses
-+
 Reporter:  lukeplant|Owner:  julien
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by julien):

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


Comment:

 In [17635]:
 {{{
 #!CommitTicketReference repository="" revision="17635"
 Fixed #17198 -- Ensured that a deterministic order is used across all
 database backends for displaying the admin change list's results. Many
 thanks to Luke Plant for the report and general approach, to everyone
 involved in the design discussions, and to Carl Meyer for the patch
 review. Refs #16819.
 }}}

-- 
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] #17819: NamedUrlWizardView doesn't correctly use the stored files

[Django]

#17819: NamedUrlWizardView doesn't correctly use the stored files
---+
 Reporter:  jezdez |Owner:  jezdez
 Type:  Bug|   Status:  closed
Component:  contrib.formtools  |  Version:  SVN
 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 jezdez):

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


Comment:

 In [17634]:
 {{{
 #!CommitTicketReference repository="" revision="17634"
 Fixed #17819 -- Convinced the NamedUrlWizardView to stop dropping files
 when stepping through the forms.
 }}}

-- 
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] r17634 - in django/trunk/django/contrib/formtools: tests/wizard/namedwizardtests wizard

[noreply]

Author: jezdez
Date: 2012-03-02 17:06:37 -0800 (Fri, 02 Mar 2012)
New Revision: 17634

Modified:
   django/trunk/django/contrib/formtools/tests/wizard/namedwizardtests/forms.py
   django/trunk/django/contrib/formtools/tests/wizard/namedwizardtests/tests.py
   django/trunk/django/contrib/formtools/wizard/views.py
Log:
Fixed #17819 -- Convinced the NamedUrlWizardView to stop dropping files when 
stepping through the forms.

Modified: 
django/trunk/django/contrib/formtools/tests/wizard/namedwizardtests/forms.py
===
--- 
django/trunk/django/contrib/formtools/tests/wizard/namedwizardtests/forms.py
2012-03-02 22:35:26 UTC (rev 17633)
+++ 
django/trunk/django/contrib/formtools/tests/wizard/namedwizardtests/forms.py
2012-03-03 01:06:37 UTC (rev 17634)
@@ -1,4 +1,8 @@
+import os
+import tempfile
+
 from django import forms
+from django.core.files.storage import FileSystemStorage
 from django.forms.formsets import formset_factory
 from django.http import HttpResponse
 from django.template import Template, Context
@@ -7,6 +11,9 @@
 
 from django.contrib.formtools.wizard.views import NamedUrlWizardView
 
+temp_storage_location = 
tempfile.mkdtemp(dir=os.environ.get('DJANGO_TEST_TEMP_DIR'))
+temp_storage = FileSystemStorage(location=temp_storage_location)
+
 class Page1(forms.Form):
 name = forms.CharField(max_length=100)
 user = forms.ModelChoiceField(queryset=User.objects.all())
@@ -15,6 +22,7 @@
 class Page2(forms.Form):
 address1 = forms.CharField(max_length=100)
 address2 = forms.CharField(max_length=100)
+file1 = forms.FileField()
 
 class Page3(forms.Form):
 random_crap = forms.CharField(max_length=100)
@@ -22,6 +30,8 @@
 Page4 = formset_factory(Page3, extra=2)
 
 class ContactWizard(NamedUrlWizardView):
+file_storage = temp_storage
+
 def done(self, form_list, **kwargs):
 c = Context({
 'form_list': [x.cleaned_data for x in form_list],

Modified: 
django/trunk/django/contrib/formtools/tests/wizard/namedwizardtests/tests.py
===
--- 
django/trunk/django/contrib/formtools/tests/wizard/namedwizardtests/tests.py
2012-03-02 22:35:26 UTC (rev 17633)
+++ 
django/trunk/django/contrib/formtools/tests/wizard/namedwizardtests/tests.py
2012-03-03 01:06:37 UTC (rev 17634)
@@ -8,6 +8,7 @@
NamedUrlCookieWizardView)
 from django.contrib.formtools.tests.wizard.forms import get_request, Step1, 
Step2
 
+
 class NamedWizardTests(object):
 urls = 'django.contrib.formtools.tests.wizard.namedwizardtests.urls'
 
@@ -30,7 +31,6 @@
 self.assertEqual(wizard['steps'].count, 4)
 self.assertEqual(wizard['url_name'], self.wizard_urlname)
 
-
 def test_initial_call_with_params(self):
 get_params = {'getvar1': 'getval1', 'getvar2': 'getval2'}
 response = self.client.get(reverse('%s_start' % self.wizard_urlname),
@@ -119,10 +119,12 @@
 self.assertEqual(response.status_code, 200)
 self.assertEqual(response.context['wizard']['steps'].current, 'form2')
 
+post_data = self.wizard_step_data[1]
+post_data['form2-file1'] = open(__file__)
 response = self.client.post(
 reverse(self.wizard_urlname,
 kwargs={'step': 
response.context['wizard']['steps'].current}),
-self.wizard_step_data[1])
+post_data)
 response = self.client.get(response['Location'])
 
 self.assertEqual(response.status_code, 200)
@@ -144,7 +146,10 @@
 response = self.client.get(response['Location'])
 self.assertEqual(response.status_code, 200)
 
-self.assertEqual(response.context['form_list'], [
+all_data = response.context['form_list']
+self.assertEqual(all_data[1]['file1'].read(), open(__file__).read())
+del all_data[1]['file1']
+self.assertEqual(all_data, [
 {'name': u'Pony', 'thirsty': True, 'user': self.testuser},
 {'address1': u'123 Main St', 'address2': u'Djangoland'},
 {'random_crap': u'blah blah'},
@@ -162,13 +167,21 @@
 response = self.client.get(response['Location'])
 self.assertEqual(response.status_code, 200)
 
+post_data = self.wizard_step_data[1]
+post_data['form2-file1'] = open(__file__)
 response = self.client.post(
 reverse(self.wizard_urlname,
 kwargs={'step': 
response.context['wizard']['steps'].current}),
-self.wizard_step_data[1])
+post_data)
 response = self.client.get(response['Location'])
 self.assertEqual(response.status_code, 200)
 
+step2_url = reverse(self.wizard_urlname, kwargs={'step': 'form2'})
+response = self.client.get(step2_url)
+self.assertEqual(response.status_code, 200)
+

Re: [Django] #17819: NamedUrlWizardView doesn't correctly use the stored files

[Django]

#17819: NamedUrlWizardView doesn't correctly use the stored files
---+
 Reporter:  jezdez |Owner:  jezdez
 Type:  Bug|   Status:  new
Component:  contrib.formtools  |  Version:  SVN
 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 jezdez):

 * version:  1.3 => SVN


-- 
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] #17819: NamedUrlWizardView doesn't correctly use the stored files

[Django]

#17819: NamedUrlWizardView doesn't correctly use the stored files
---+
 Reporter:  jezdez |Owner:  jezdez
 Type:  Bug|   Status:  new
Component:  contrib.formtools  |  Version:  1.3
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by jezdez):

 * owner:  nobody => jezdez


-- 
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] #17819: NamedUrlWizardView doesn't correctly use the stored files

[Django]

#17819: NamedUrlWizardView doesn't correctly use the stored files
-+
   Reporter:  jezdez |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.formtools  |Version:  1.3
   Severity:  Release blocker|   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Seems like this is broken:

 
https://code.djangoproject.com/browser/django/trunk/django/contrib/formtools/wizard/views.py?rev=17236#L627
 
https://code.djangoproject.com/browser/django/trunk/django/contrib/formtools/wizard/views.py?rev=17236#L634

-- 
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] #14147: django 1.2 documentation refer to assertQuerysetEqual which is only available in trunk

[Django]

#14147: django 1.2 documentation refer to assertQuerysetEqual which is only
available in trunk
-+-
 Reporter:  djoume   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   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
-+-

Comment (by carljm):

 Replying to [comment:7 codysomerville]:
 > For what it's worth, it is confusing that the documentation is
 inaccurate.

 Hi Cody - I'm confused about what is inaccurate/confusing in the
 documentation. The documentation bug reported here is fixed; if you think
 there's still a bug in the docs, please report it in a new ticket. Thanks!

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

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

Re: [Django] #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):

 As the field length is just 3 chars the amount of data from the parameters
 is roughly 30KB. If you make the field length, say 30 chars, then it
 should trigger the problem if it exists at all.

 I suspect it doesn't. I have googled this a little, and people do not
 complain about this often. If the parameters were calculated into the
 query string length, then I expect there would be more complaints.

-- 
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 aaugustin):

 For the record here's the diff I used:
 {{{

 Index: tests/regressiontests/test_17788/__init__.py
 ===
 Index: tests/regressiontests/test_17788/tests.py
 ===
 --- tests/regressiontests/test_17788/tests.py   (revision 0)
 +++ tests/regressiontests/test_17788/tests.py   (revision 0)
 @@ -0,0 +1,8 @@
 +from django.test import TestCase
 +
 +from .models import SomeModel
 +
 +class SomeTest(TestCase):
 +
 +def test_bulk_insert(self):
 +SomeModel.objects.bulk_create(SomeModel(f='abc') for i in
 range(0, 1))
 Index: tests/regressiontests/test_17788/models.py
 ===
 --- tests/regressiontests/test_17788/models.py  (revision 0)
 +++ tests/regressiontests/test_17788/models.py  (revision 0)
 @@ -0,0 +1,4 @@
 +from django.db import models
 +
 +class SomeModel(models.Model):
 +f = models.CharField(max_length=100)
 }}}

 This test passes under Oracle.

-- 
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] r17633 - in django/trunk: django/middleware tests/regressiontests/i18n/patterns

[noreply]

Author: jezdez
Date: 2012-03-02 14:35:26 -0800 (Fri, 02 Mar 2012)
New Revision: 17633

Modified:
   django/trunk/django/middleware/locale.py
   django/trunk/tests/regressiontests/i18n/patterns/tests.py
Log:
Fixed #17817 -- Modified LocalMiddleware to use full URLs when redirecting to 
i18n URLs. Thanks to Paul for keeping an eye on the standards.

Modified: django/trunk/django/middleware/locale.py
===
--- django/trunk/django/middleware/locale.py2012-03-02 22:32:22 UTC (rev 
17632)
+++ django/trunk/django/middleware/locale.py2012-03-02 22:35:26 UTC (rev 
17633)
@@ -33,9 +33,12 @@
 language_path = '/%s%s' % (language, request.path_info)
 if settings.APPEND_SLASH and not language_path.endswith('/'):
 language_path = language_path + '/'
+
 if is_valid_path(language_path, urlconf):
-return HttpResponseRedirect(
-'/%s%s' % (language, request.get_full_path()))
+language_url = "%s://%s/%s%s" % (
+request.is_secure() and 'https' or 'http',
+request.get_host(), language, request.get_full_path())
+return HttpResponseRedirect(language_url)
 translation.deactivate()
 
 patch_vary_headers(response, ('Accept-Language',))

Modified: django/trunk/tests/regressiontests/i18n/patterns/tests.py
===
--- django/trunk/tests/regressiontests/i18n/patterns/tests.py   2012-03-02 
22:32:22 UTC (rev 17632)
+++ django/trunk/tests/regressiontests/i18n/patterns/tests.py   2012-03-02 
22:35:26 UTC (rev 17633)
@@ -182,14 +182,12 @@
 self.assertRedirects(response, '/not-prefixed/', 301)
 
 def test_en_redirect(self):
-response = self.client.get('/account/register', 
HTTP_ACCEPT_LANGUAGE='en')
+response = self.client.get('/account/register', 
HTTP_ACCEPT_LANGUAGE='en', follow=True)
 # target status code of 301 because of CommonMiddleware redirecting
-self.assertRedirects(response, '/en/account/register', 302, 
target_status_code=301)
+self.assertIn(('http://testserver/en/account/register/', 301), 
response.redirect_chain)
+self.assertRedirects(response, '/en/account/register/', 302)
 
-response = self.client.get(response['location'])
-self.assertRedirects(response, '/en/account/register/', 301)
 
-
 class URLRedirectWithoutTrailingSlashSettingTests(URLTestCaseBase):
 """
 Tests the redirect when the requested URL doesn't end with a slash

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #17817: Django should not send invalid Location headers

[Django]

#17817: Django should not send invalid Location headers
-+-
 Reporter:  PaulM|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:
  Internationalization   |  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 jezdez):

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


Comment:

 In [17633]:
 {{{
 #!CommitTicketReference repository="" revision="17633"
 Fixed #17817 -- Modified LocalMiddleware to use full URLs when redirecting
 to i18n URLs. Thanks to Paul for keeping an eye on the standards.
 }}}

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

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

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

[Django]

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

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


Comment:

 In [17632]:
 {{{
 #!CommitTicketReference repository="" revision="17632"
 Fixed #15169 -- Added conversion of 0/1 to False/True for MySQL GIS
 backend. Thanks zmsmith for report, and Ramiro for draft patch and 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.

[Changeset] r17632 - in django/trunk/django/contrib/gis: db/backends/mysql tests/geoapp

[noreply]

Author: carljm
Date: 2012-03-02 14:32:22 -0800 (Fri, 02 Mar 2012)
New Revision: 17632

Added:
   django/trunk/django/contrib/gis/db/backends/mysql/compiler.py
Modified:
   django/trunk/django/contrib/gis/db/backends/mysql/operations.py
   django/trunk/django/contrib/gis/tests/geoapp/models.py
   django/trunk/django/contrib/gis/tests/geoapp/test_regress.py
Log:
Fixed #15169 -- Added conversion of 0/1 to False/True for MySQL GIS backend. 
Thanks zmsmith for report, and Ramiro for draft patch and review.

Added: django/trunk/django/contrib/gis/db/backends/mysql/compiler.py
===
--- django/trunk/django/contrib/gis/db/backends/mysql/compiler.py   
(rev 0)
+++ django/trunk/django/contrib/gis/db/backends/mysql/compiler.py   
2012-03-02 22:32:22 UTC (rev 17632)
@@ -0,0 +1,32 @@
+from django.contrib.gis.db.models.sql.compiler import GeoSQLCompiler as 
BaseGeoSQLCompiler
+from django.db.backends.mysql import compiler
+
+SQLCompiler = compiler.SQLCompiler
+
+class GeoSQLCompiler(BaseGeoSQLCompiler, SQLCompiler):
+def resolve_columns(self, row, fields=()):
+"""
+Integrate the cases handled both by the base GeoSQLCompiler and the
+main MySQL compiler (converting 0/1 to True/False for boolean fields).
+
+Refs #15169.
+
+"""
+row = BaseGeoSQLCompiler.resolve_columns(self, row, fields)
+return SQLCompiler.resolve_columns(self, row, fields)
+
+
+class SQLInsertCompiler(compiler.SQLInsertCompiler, GeoSQLCompiler):
+pass
+
+class SQLDeleteCompiler(compiler.SQLDeleteCompiler, GeoSQLCompiler):
+pass
+
+class SQLUpdateCompiler(compiler.SQLUpdateCompiler, GeoSQLCompiler):
+pass
+
+class SQLAggregateCompiler(compiler.SQLAggregateCompiler, GeoSQLCompiler):
+pass
+
+class SQLDateCompiler(compiler.SQLDateCompiler, GeoSQLCompiler):
+pass

Modified: django/trunk/django/contrib/gis/db/backends/mysql/operations.py
===
--- django/trunk/django/contrib/gis/db/backends/mysql/operations.py 
2012-03-02 20:34:46 UTC (rev 17631)
+++ django/trunk/django/contrib/gis/db/backends/mysql/operations.py 
2012-03-02 22:32:22 UTC (rev 17632)
@@ -5,7 +5,7 @@
 
 class MySQLOperations(DatabaseOperations, BaseSpatialOperations):
 
-compiler_module = 'django.contrib.gis.db.models.sql.compiler'
+compiler_module = 'django.contrib.gis.db.backends.mysql.compiler'
 mysql = True
 name = 'mysql'
 select = 'AsText(%s)'

Modified: django/trunk/django/contrib/gis/tests/geoapp/models.py
===
--- django/trunk/django/contrib/gis/tests/geoapp/models.py  2012-03-02 
20:34:46 UTC (rev 17631)
+++ django/trunk/django/contrib/gis/tests/geoapp/models.py  2012-03-02 
22:32:22 UTC (rev 17632)
@@ -34,6 +34,10 @@
 objects = models.GeoManager()
 def __unicode__(self): return self.name
 
+class Truth(models.Model):
+val = models.BooleanField()
+objects = models.GeoManager()
+
 if not spatialite:
 class Feature(models.Model):
 name = models.CharField(max_length=20)

Modified: django/trunk/django/contrib/gis/tests/geoapp/test_regress.py
===
--- django/trunk/django/contrib/gis/tests/geoapp/test_regress.py
2012-03-02 20:34:46 UTC (rev 17631)
+++ django/trunk/django/contrib/gis/tests/geoapp/test_regress.py
2012-03-02 22:32:22 UTC (rev 17632)
@@ -7,7 +7,7 @@
 from django.db.models import Count
 from django.test import TestCase
 
-from .models import City, PennsylvaniaCity, State
+from .models import City, PennsylvaniaCity, State, Truth
 
 
 class GeoRegressionTests(TestCase):
@@ -64,3 +64,17 @@
 "Regression for #16409. Make sure defer() and only() work with 
annotate()"
 
self.assertIsInstance(list(City.objects.annotate(Count('point')).defer('name')),
 list)
 
self.assertIsInstance(list(City.objects.annotate(Count('point')).only('name')), 
list)
+
+def test07_boolean_conversion(self):
+"Testing Boolean value conversion with the spatial backend, see 
#15169."
+t1 = Truth.objects.create(val=True)
+t2 = Truth.objects.create(val=False)
+
+val1 = Truth.objects.get(pk=1).val
+val2 = Truth.objects.get(pk=2).val
+# verify types -- should't be 0/1
+self.assertIsInstance(val1, bool)
+self.assertIsInstance(val2, bool)
+# verify values
+self.assertEqual(val1, True)
+self.assertEqual(val2, False)

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

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

[Django]

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

Comment (by aaugustin):

 ci.djangoproject.com now runs tests with the MySQL GIS backend :)

-- 
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] #17818: Generic edit generic views don't create `fail_silently` success messages anymore.

[Django]

#17818: Generic edit generic views don't create `fail_silently` success messages
anymore.
---+-
 Reporter:  charettes  |  Owner:  charettes
 Type:  Uncategorized  | Status:  new
Component:  Generic views  |Version:  1.3
 Severity:  Normal |   Keywords:  views generic edit messages
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+-
 It looks like the creation of success messages on valid form submission
 was oversight when the generic class based views were designed.

 Here's a link to the [https://groups.google.com/forum/#!topic/django-
 developers/3UcEeutA5Qg django-developper discussion] that motivated the
 creation of this ticket.

 I'm also attaching a patch (with no tests and docs) that provide a simple
 yet overridable implementation that mimic the deprecated function based
 behaviour.

-- 
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] #14147: django 1.2 documentation refer to assertQuerysetEqual which is only available in trunk

[Django]

#14147: django 1.2 documentation refer to assertQuerysetEqual which is only
available in trunk
-+-
 Reporter:  djoume   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   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 codysomerville):

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


Comment:

 For what it's worth, it is confusing that the documentation is inaccurate.

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

[noreply]

Author: carljm
Date: 2012-03-02 12:34:46 -0800 (Fri, 02 Mar 2012)
New Revision: 17631

Modified:
   django/trunk/django/core/management/commands/makemessages.py
Log:
Added missing newline to makemessages output. Thanks Florian Apolloner for 
report and patch.

Modified: django/trunk/django/core/management/commands/makemessages.py
===
--- django/trunk/django/core/management/commands/makemessages.py
2012-03-02 17:16:52 UTC (rev 17630)
+++ django/trunk/django/core/management/commands/makemessages.py
2012-03-02 20:34:46 UTC (rev 17631)
@@ -324,7 +324,7 @@
 
 for locale in locales:
 if verbosity > 0:
-stdout.write("processing language %s" % locale)
+stdout.write("processing language %s\n" % locale)
 basedir = os.path.join(localedir, locale, 'LC_MESSAGES')
 if not os.path.isdir(basedir):
 os.makedirs(basedir)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #4113: dynamic destinations for FileField.upload_to

[Django]

#4113: dynamic destinations for FileField.upload_to
-+-
 Reporter:  August Bigelow   |Owner:  nobody
  |   Status:  closed
 Type:  Uncategorized|  Version:  SVN
Component:  Core (Other) |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

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


Comment:

 Agreed ,class TestModel(Model): http://www.wvweightloss.com/

-- 
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] #17769: RTL from in admin panel css

[Django]

#17769: RTL from in admin panel css
--+
 Reporter:  shark4313@…   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:  rtl   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  1
--+
Changes (by jezdez):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 0
 * ui_ux:  0 => 1
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #17795: kwargs not passed on by django.views.generic.edit import ProcessFormView

[Django]

#17795: kwargs not passed on by django.views.generic.edit import ProcessFormView
-+-
 Reporter:  ed.crewe@…   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Generic views|  1.4-beta-1
 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 jezdez):

 * 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] #17795: kwargs not passed on by django.views.generic.edit import ProcessFormView

[Django]

#17795: kwargs not passed on by django.views.generic.edit import ProcessFormView
-+-
 Reporter:  ed.crewe@…   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Generic views|  1.4-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Description changed by jezdez:

Old description:

> Although these do get attached to self.kwargs for use within the class,
> this causes problems for decorators of the get_context_data method.
>
> kwargs which you may expect to be available for use by decorators you
> create are unset by this mixin.
>
> NB: In my case this was related to testing user object permissions -
> hence the need to have the context data
>
> Patching as below fixes it:
>
> {{{
> A mixin that processes a form on POST.
> """
> def get(self, request, *args, **kwargs):
> form_class = self.get_form_class()
> form = self.get_form(form_class)
> --  return self.render_to_response(self.get_context_data(form=form))
> ++  kwargs['form'] = form
> ++  return self.render_to_response(self.get_context_data(**kwargs))
>
>  }}}

New description:

 Although these do get attached to self.kwargs for use within the class,
 this causes problems for decorators of the get_context_data method.

 kwargs which you may expect to be available for use by decorators you
 create are unset by this mixin.

 NB: In my case this was related to testing user object permissions - hence
 the need to have the context data

 Patching as below fixes it:

 {{{
 A mixin that processes a form on POST.
 """
 def get(self, request, *args, **kwargs):
 form_class = self.get_form_class()
 form = self.get_form(form_class)
 --  return self.render_to_response(self.get_context_data(form=form))
 ++  kwargs['form'] = form
 ++  return self.render_to_response(self.get_context_data(**kwargs))
  }}}

--

-- 
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] #17795: kwargs not passed on by django.views.generic.edit import ProcessFormView

[Django]

#17795: kwargs not passed on by django.views.generic.edit import ProcessFormView
-+-
 Reporter:  ed.crewe@…   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Generic views|  1.4-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Old description:

> Although these do get attached to self.kwargs for use within the class,
> this causes problems for decorators of the get_context_data method.
>
> kwargs which you may expect to be available for use by decorators you
> create are unset by this mixin.
>
> NB: In my case this was related to testing user object permissions -
> hence the need to have the context data
>
> Patching as below fixes it:
>
> A mixin that processes a form on POST.
> """
> def get(self, request, *args, **kwargs):
> form_class = self.get_form_class()
> form = self.get_form(form_class)
> --  return self.render_to_response(self.get_context_data(form=form))
> ++  kwargs['form'] = form
> ++  return self.render_to_response(self.get_context_data(**kwargs))

New description:

 Although these do get attached to self.kwargs for use within the class,
 this causes problems for decorators of the get_context_data method.

 kwargs which you may expect to be available for use by decorators you
 create are unset by this mixin.

 NB: In my case this was related to testing user object permissions - hence
 the need to have the context data

 Patching as below fixes it:

 {{{
 A mixin that processes a form on POST.
 """
 def get(self, request, *args, **kwargs):
 form_class = self.get_form_class()
 form = self.get_form(form_class)
 --  return self.render_to_response(self.get_context_data(form=form))
 ++  kwargs['form'] = form
 ++  return self.render_to_response(self.get_context_data(**kwargs))

  }}}

--

Comment (by jezdez):

 Updated ticket description.

-- 
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] #17798: minor changes in localflavor.ca.ca_provinces

[Django]

#17798: minor changes in localflavor.ca.ca_provinces
--+
 Reporter:  shelldweller  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.localflavor   |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by jezdez):

 * needs_docs:  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] #17798: minor changes in localflavor.ca.ca_provinces

[Django]

#17798: minor changes in localflavor.ca.ca_provinces
--+
 Reporter:  shelldweller  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.localflavor   |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by jezdez):

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


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

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

Re: [Django] #17801: Adding DummyCache causes contrib.session tests to fail

[Django]

#17801: Adding DummyCache causes contrib.session tests to fail
-+-
 Reporter:  d0ugal   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Cache system)  |  Version:
 Severity:  Normal   |  1.4-beta-1
 Keywords:   |   Resolution:  wontfix
Has patch:  0| Triage Stage:
  Needs tests:  0|  Unreviewed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by jezdez):

 * status:  new => closed
 * needs_better_patch:   => 0
 * component:  contrib.sessions => Core (Cache system)
 * needs_tests:   => 0
 * needs_docs:   => 0
 * resolution:   => wontfix


Comment:

 This is an expected behavior since the dummy cache returns False by
 default when calling its `has_key` method (which is done by the
 `cached_db` and `cache` session backends' `exists` method) .

 The workaround is to use the locmem cache backend instead.

-- 
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] #17817: Django should not send invalid Location headers

[Django]

#17817: Django should not send invalid Location headers
-+-
   Reporter:  PaulM  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  1.4-beta-1
  Internationalization   |   Keywords:
   Severity:  Release|  Has patch:  0
  blocker|Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 Django's locale middleware currently includes code which generates
 Location headers with relative URIs.

 According to RFC 1945 and 2616, Location headers must be constructed with
 an absolute URI. While some user agents may support the non-compliant
 behavior, Django itself should not rely on this, and should generate
 absolute URIs as it does elsewhere.

 http://tools.ietf.org/html/rfc2616#section-14.30

 
https://code.djangoproject.com/browser/django/trunk/django/middleware/locale.py?rev=16405=name#L30

-- 
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] #17811: Connection object is no passed to the EmailMessage constructor when called from send_mass_mail

[Django]

#17811: Connection object is no passed to the EmailMessage constructor when 
called
from send_mass_mail
-+-
 Reporter:  fed239   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  mail, connection,| Triage Stage:  Accepted
  email  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by jezdez):

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


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

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

Re: [Django] #17804: Django Admin's input for BigIntegerField should be larger

[Django]

#17804: Django Admin's input for BigIntegerField should be larger
---+
 Reporter:  Adys   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+
Changes (by jezdez):

 * needs_better_patch:   => 0
 * component:  Uncategorized => contrib.admin
 * needs_tests:   => 0
 * needs_docs:   => 0
 * ui_ux:  0 => 1
 * type:  Uncategorized => Bug
 * 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] #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
-+-
Changes (by jezdez):

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


Comment:

 What version of Ubuntu did you use? Which version of Python? Which of
 Django? What kind of deployment did you use?

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

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

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

 OK, seems like I am not going to test this on Oracle. Installing Oracle XE
 is ridiculously hard, and now I have half-configures Oracle XE
 installed...

 So, if somebody could test the following on Oralce:
 {{{
 class SomeModel(models.Model):
 f = models.CharField(max_length=100)
 SomeModel.objects.bulk_create(SomeModel(f='a'*100) for i in range(0,
 1000))
 }}}
 If that works, increase the 1000 to say 1. If no problems, I guess
 Oracle is safe enough for 1.4.

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

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

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

[Django]

#17816: UnicodeEncodeError in Image- and FileFields
--+
 Reporter:  andi@…|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Forms |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Uploading files (and images) containing non-ASCII characters (e.g. German
 umlauts) with a form containing an ImageField or FileField causes a
 UnicodeEncodeError on recent versions of Ubuntu servers. Curiously this
 does not happen on the development-server or older Debian 5 servers.

 In order to avoid this error and non-ASCII characters in URLs I'd like to
 suggest a built-in (optional) conversion of the filename in the Image-
 and/or FileField class (or corresponding base class).

 {{{
 class MyImageField(ImageField):

 def __init__(self, *args, **kwargs):
 super(MyImageField, self).__init__(*args, **kwargs)

 def clean(self, *args, **kwargs):
 data = super(MyImageField, self).clean(*args, **kwargs)
 filename = os.path.splitext(data.name)
 data.name = unicode(data.name)
 if len(filename[1]):
 data.name += u'.'+slugify(filename[1])
 return data
 }}}
 where slugify is e.g. the slugify function from
 django.template.defaultfilters

-- 
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|
-+-
Changes (by carljm):

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


Comment:

 I really hate the use of a setting for this (despite the precedent of
 `ABSOLUTE_URL_OVERRIDES`, which I don't like either). I do think it's a
 problem that Django should provide some answer for, so accepting the
 ticket on that basis. I can't immediately think of a better solution than
 the setting, but I hope we can think of one.

-- 
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:  new
Component:  Translations  |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by claudep):

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


Comment:

 The plural forms are defined by the Transifex platform used now for Django
 translations.[[BR]]
 Could you please open a bug report in Transifex?
 http://trac.transifex.org/newticket

-- 
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] #17564: django.db.models.Sum does not work on BooleanField

[Django]

#17564: django.db.models.Sum does not work on BooleanField
-+-
 Reporter:  dp_wiz   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  postgresql   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 Can you please explain how to do it through django without using the
 patch?

 Replying to [comment:2 akaariai]:
 > The problem here is that PostgreSQL would need a type cast to int. So,
 the SQL should look like SUM("some_boolean_field"::int) for the SUM to
 work. However I am not sure if doing this in Django is a good idea, mainly
 because this would complicate the code somewhat, and something like #11305
 would solve the issue for the user by allowing generation of SQL like in
 the Mozilla bug report.
 >
 > I am leaving this ticket still open, although I would like to close this
 as wontfix for the reasons mentioned above. Could this be marked duplicate
 (or "related to") to #11305?

-- 
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] r17630 - in django/trunk: django/contrib/gis/tests/geoapp django/db/models docs/howto docs/howto/deployment/wsgi docs/intro docs/ref docs/releases docs/topics docs/topics/db tests/regress

[noreply]

Author: adrian
Date: 2012-03-02 09:16:52 -0800 (Fri, 02 Mar 2012)
New Revision: 17630

Modified:
   django/trunk/django/contrib/gis/tests/geoapp/test_regress.py
   django/trunk/django/db/models/options.py
   django/trunk/docs/howto/deployment/wsgi/uwsgi.txt
   django/trunk/docs/howto/initial-data.txt
   django/trunk/docs/intro/tutorial01.txt
   django/trunk/docs/intro/tutorial02.txt
   django/trunk/docs/ref/databases.txt
   django/trunk/docs/ref/django-admin.txt
   django/trunk/docs/ref/request-response.txt
   django/trunk/docs/ref/settings.txt
   django/trunk/docs/ref/utils.txt
   django/trunk/docs/releases/1.4.txt
   django/trunk/docs/topics/auth.txt
   django/trunk/docs/topics/db/queries.txt
   django/trunk/docs/topics/testing.txt
   django/trunk/tests/regressiontests/admin_views/tests.py
Log:
Edited stuff from [17543] to [17629]

Modified: django/trunk/django/contrib/gis/tests/geoapp/test_regress.py
===
--- django/trunk/django/contrib/gis/tests/geoapp/test_regress.py
2012-03-02 17:13:53 UTC (rev 17629)
+++ django/trunk/django/contrib/gis/tests/geoapp/test_regress.py
2012-03-02 17:16:52 UTC (rev 17630)
@@ -13,7 +13,7 @@
 class GeoRegressionTests(TestCase):
 
 def test01_update(self):
-"Testing GeoQuerySet.update(), see #10411."
+"Testing GeoQuerySet.update(). See #10411."
 pnt = City.objects.get(name='Pueblo').point
 bak = pnt.clone()
 pnt.y += 0.005
@@ -25,7 +25,7 @@
 self.assertEqual(bak, City.objects.get(name='Pueblo').point)
 
 def test02_kmz(self):
-"Testing `render_to_kmz` with non-ASCII data, see #11624."
+"Testing `render_to_kmz` with non-ASCII data. See #11624."
 name = '\xc3\x85land Islands'.decode('iso-8859-1')
 places = [{'name' : name,
   'description' : name,
@@ -36,7 +36,7 @@
 @no_spatialite
 @no_mysql
 def test03_extent(self):
-"Testing `extent` on a table with a single point, see #11827."
+"Testing `extent` on a table with a single point. See #11827."
 pnt = City.objects.get(name='Pueblo').point
 ref_ext = (pnt.x, pnt.y, pnt.x, pnt.y)
 extent = City.objects.filter(name='Pueblo').extent()
@@ -44,14 +44,14 @@
 self.assertAlmostEqual(ref_val, val, 4)
 
 def test04_unicode_date(self):
-"Testing dates are converted properly, even on SpatiaLite, see #16408."
+"Testing dates are converted properly, even on SpatiaLite. See #16408."
 founded = datetime(1857, 5, 23)
 mansfield = PennsylvaniaCity.objects.create(name='Mansfield', 
county='Tioga', point='POINT(-77.071445 41.823881)',
 founded=founded)
 self.assertEqual(founded, PennsylvaniaCity.objects.dates('founded', 
'day')[0])
 
 def test05_empty_count(self):
- "Testing that PostGISAdapter.__eq__ does check empty strings, see 
#13670"
+ "Testing that PostGISAdapter.__eq__ does check empty strings. See 
#13670."
  # contrived example, but need a geo lookup paired with an id__in 
lookup
  pueblo = City.objects.get(name='Pueblo')
  state = State.objects.filter(poly__contains=pueblo.point)
@@ -61,6 +61,6 @@
  self.assertEqual(cities_within_state.count(), 1)
 
 def test06_defer_or_only_with_annotate(self):
-"Regression for #16409 - make sure defer() and only() work with 
annotate()"
+"Regression for #16409. Make sure defer() and only() work with 
annotate()"
 
self.assertIsInstance(list(City.objects.annotate(Count('point')).defer('name')),
 list)
 
self.assertIsInstance(list(City.objects.annotate(Count('point')).only('name')), 
list)

Modified: django/trunk/django/db/models/options.py
===
--- django/trunk/django/db/models/options.py2012-03-02 17:13:53 UTC (rev 
17629)
+++ django/trunk/django/db/models/options.py2012-03-02 17:16:52 UTC (rev 
17630)
@@ -40,15 +40,15 @@
 self.abstract = False
 self.managed = True
 self.proxy = False
-# For any class which is a proxy (including automatically created
-# classes for deferred object loading) the proxy_for_model tells
+# For any class that is a proxy (including automatically created
+# classes for deferred object loading), proxy_for_model tells us
 # which class this model is proxying. Note that proxy_for_model
-# can create a chain of proxy models. For non-proxy models the
+# can create a chain of proxy models. For non-proxy models, the
 # variable is always None.
 self.proxy_for_model = None
-# For any non-abstract class the concrete class is the model
+# For any non-abstract class, the concrete class is the model
 # in the end of the proxy_for_model chain. In particular, for
-# 

[Changeset] r17629 - in django/trunk/docs: howto ref

[noreply]

Author: carljm
Date: 2012-03-02 09:13:53 -0800 (Fri, 02 Mar 2012)
New Revision: 17629

Modified:
   django/trunk/docs/howto/custom-management-commands.txt
   django/trunk/docs/ref/django-admin.txt
Log:
Fixed #17799 - Documented that the execute() method of a management command is 
not suitable for calling the command from code; call_command should be used 
instead. Thanks kacah222 for the report and claudep for the patch.

Modified: django/trunk/docs/howto/custom-management-commands.txt
===
--- django/trunk/docs/howto/custom-management-commands.txt  2012-03-02 
16:56:20 UTC (rev 17628)
+++ django/trunk/docs/howto/custom-management-commands.txt  2012-03-02 
17:13:53 UTC (rev 17629)
@@ -243,6 +243,11 @@
 :class:`CommandError`, intercept it and print it sensibly to
 stderr.
 
+.. admonition:: Calling a management command in your code
+
+``execute()`` should not be called directly from your code to execute a
+command. Use :ref:`call_command ` instead.
+
 .. method:: BaseCommand.handle(*args, **options)
 
 The actual logic of the command. Subclasses must implement this method.

Modified: django/trunk/docs/ref/django-admin.txt
===
--- django/trunk/docs/ref/django-admin.txt  2012-03-02 16:56:20 UTC (rev 
17628)
+++ django/trunk/docs/ref/django-admin.txt  2012-03-02 17:13:53 UTC (rev 
17629)
@@ -1490,6 +1490,8 @@
 Running management commands from your code
 ==
 
+.. _call-command:
+
 .. function:: django.core.management.call_command(name, *args, **options)
 
 To call a management command from code use ``call_command``.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #17799: Default parameters in syncdb.Command().Execute()

[Django]

#17799: Default parameters in syncdb.Command().Execute()
-+-
 Reporter:  kacah222@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:
  commands)  |  1.4-beta-1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  syncdb   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by carljm):

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


Comment:

 In [17629]:
 {{{
 #!CommitTicketReference repository="" revision="17629"
 Fixed #17799 - Documented that the execute() method of a management
 command is not suitable for calling the command from code; call_command
 should be used instead. Thanks kacah222 for the report and claudep for the
 patch.
 }}}

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

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

[Django] #17815: Turkish plural forms incorrect

[Django]

#17815: Turkish plural forms incorrect
--+
 Reporter:  dave@…|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Translations  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Turkish plural forms in conf/locale/tr/LC_MESSAGES/django.po are
 currently:
 "Plural-Forms: nplurals=1; plural=0\n"

 This is incorrect, they should be:
 "Plural-Forms: nplurals=2; plural=(n>1)\n"

 Ref: http://translate.sourceforge.net/wiki/l10n/pluralforms

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

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

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

[Django]

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

Comment (by carljm):

 Replying to [comment:12 valexeev]:
 > I was thinking about working on documentation for it, but I'm not sure
 where to start, and, first of all, why changes to the documentation are
 needed at all.
 >
 > For me it seems like this change concerns itself with lower-level API
 and so does only matter for someone who is working on a custom form Field.
 But this topic isn't documented at all at the moment, so there's just no
 documentation to be updated.
 >
 > Please correct me if I'm wrong.

 It's true that there is no documentation specifically targeted at authors
 of custom field subclasses. However, as Russell pointed out above,
 `MultiValueField`
 [https://docs.djangoproject.com/en/dev/ref/forms/fields/#multivaluefield
 is documented], even though it must be subclassed to be useful. So I think
 the documentation that would make sense here would basically be to move
 (or copy) the docstring addition from the current patch as a note in the
 `MultiValueField` documentation.

-- 
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] #17046: User.objects.create_user() allows empty usernames

[Django]

#17046: User.objects.create_user() allows empty usernames
-+-
 Reporter:  honza|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by jezdez):

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


Comment:

 In [17628]:
 {{{
 #!CommitTicketReference repository="" revision="17628"
 Fixed #17046 -- Added a check if the username passed to
 User.objects.create_user is empty or not. Thanks, kwadrat.
 }}}

-- 
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] r17628 - in django/trunk: django/contrib/auth django/contrib/auth/tests docs/topics

[noreply]

Author: jezdez
Date: 2012-03-02 08:56:20 -0800 (Fri, 02 Mar 2012)
New Revision: 17628

Modified:
   django/trunk/django/contrib/auth/models.py
   django/trunk/django/contrib/auth/tests/models.py
   django/trunk/docs/topics/auth.txt
Log:
Fixed #17046 -- Added a check if the username passed to 
User.objects.create_user is empty or not. Thanks, kwadrat.

Modified: django/trunk/django/contrib/auth/models.py
===
--- django/trunk/django/contrib/auth/models.py  2012-03-02 16:56:11 UTC (rev 
17627)
+++ django/trunk/django/contrib/auth/models.py  2012-03-02 16:56:20 UTC (rev 
17628)
@@ -149,6 +149,8 @@
 Creates and saves a User with the given username, email and password.
 """
 now = timezone.now()
+if not username:
+raise ValueError('The given username must be set')
 email = UserManager.normalize_email(email)
 user = self.model(username=username, email=email,
   is_staff=False, is_active=True, is_superuser=False,

Modified: django/trunk/django/contrib/auth/tests/models.py
===
--- django/trunk/django/contrib/auth/tests/models.py2012-03-02 16:56:11 UTC 
(rev 17627)
+++ django/trunk/django/contrib/auth/tests/models.py2012-03-02 16:56:20 UTC 
(rev 17628)
@@ -91,3 +91,8 @@
 def test_create_user_email_domain_normalize_with_whitespace(self):
 returned = UserManager.normalize_email('email\ with_whitesp...@d.com')
 self.assertEquals(returned, 'email\ with_whitesp...@d.com')
+
+def test_empty_username(self):
+self.assertRaisesMessage(ValueError,
+ 'The given username must be set',
+  User.objects.create_user, username='')

Modified: django/trunk/docs/topics/auth.txt
===
--- django/trunk/docs/topics/auth.txt   2012-03-02 16:56:11 UTC (rev 17627)
+++ django/trunk/docs/topics/auth.txt   2012-03-02 16:56:20 UTC (rev 17628)
@@ -280,7 +280,9 @@
 .. method:: models.UserManager.create_user(username, email=None, 
password=None)
 
 .. versionchanged:: 1.4
-   The ``email`` parameter was made optional.
+   The ``email`` parameter was made optional. The username
+   parameter is now checked for emptiness and raises a
+   :exc:`ValueError` in case of a negative result.
 
 Creates, saves and returns a :class:`~django.contrib.auth.models.User`.
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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):

 I am  going to test if Oracle has any batch size limits.

 For PostgreSQL there is no practical limit. I tested this and once you go
 to millions of objects you could OOM your server, but most likely you will
 OOM your Python process before that.

 For what I know MySQL does not have any practical limit either. 16Mb of
 query string should be enough for everybody(tm).

 Oracle is an open question, and then there are all the third party
 databases. It would maybe be worth to have an API of
 get_next_batch(param_count, params). For example sqlite could return
 min(1000/param_count, len(params)/param_count).

-- 
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] #17723: Documentation update for language code URL sniffing regression

[Django]

#17723: Documentation update for language code URL sniffing regression
-+-
 Reporter:  ryankask |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:
 Severity:  Normal   |  1.4-beta-1
 Keywords:   |   Resolution:  fixed
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  1|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by jezdez):

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


Comment:

 In [17627]:
 {{{
 #!CommitTicketReference repository="" revision="17627"
 Fixed #17723 -- Mentioned the changes done in r17547. Thanks, ryankask.
 }}}

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

[noreply]

Author: jezdez
Date: 2012-03-02 08:56:11 -0800 (Fri, 02 Mar 2012)
New Revision: 17627

Modified:
   django/trunk/docs/ref/utils.txt
Log:
Fixed #17723 -- Mentioned the changes done in r17547. Thanks, ryankask.

Modified: django/trunk/docs/ref/utils.txt
===
--- django/trunk/docs/ref/utils.txt 2012-03-02 16:56:04 UTC (rev 17626)
+++ django/trunk/docs/ref/utils.txt 2012-03-02 16:56:11 UTC (rev 17627)
@@ -591,13 +591,19 @@
 * ``False`` = left-to-right layout
 * ``True`` = right-to-left layout
 
-.. function:: get_language_from_request(request)
+.. function:: get_language_from_request(request, check_path=False)
 
+.. versionchanged:: 1.4
+
 Analyzes the request to find what language the user wants the system to 
show.
 Only languages listed in settings.LANGUAGES are taken into account. If the 
user
 requests a sublanguage where we have a main language, we send out the main
 language.
 
+If ``check_path`` is ``True`` the function first checks the requested URL
+whether its path begins with a language code listed in the
+:setting:`LANGUAGES` setting.
+
 .. function:: to_locale(language)
 
 Turns a language name (en-us) into a locale name (en_US).

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #17568: i18n_patterns and LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL

[Django]

#17568: i18n_patterns and LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL
-+-
 Reporter:  anonymous|Owner:  neaf
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:
 Severity:  Normal   |  1.4-alpha-1
 Keywords:   |   Resolution:  fixed
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by jezdez):

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


Comment:

 In [17626]:
 {{{
 #!CommitTicketReference repository="" revision="17626"
 Fixed #17568 -- Mentioned ``reverse_lazy`` in the ``LOGIN_REDIRECT_URL``
 settings docs. Thanks, zsiciarz.
 }}}

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

[noreply]

Author: jezdez
Date: 2012-03-02 08:56:04 -0800 (Fri, 02 Mar 2012)
New Revision: 17626

Modified:
   django/trunk/docs/ref/settings.txt
   django/trunk/docs/topics/http/urls.txt
Log:
Fixed #17568 -- Mentioned ``reverse_lazy`` in the ``LOGIN_REDIRECT_URL`` 
settings docs. Thanks, zsiciarz.

Modified: django/trunk/docs/ref/settings.txt
===
--- django/trunk/docs/ref/settings.txt  2012-03-02 16:55:56 UTC (rev 17625)
+++ django/trunk/docs/ref/settings.txt  2012-03-02 16:56:04 UTC (rev 17626)
@@ -1339,6 +1339,26 @@
 This is used by the :func:`~django.contrib.auth.decorators.login_required`
 decorator, for example.
 
+.. _`note on LOGIN_REDIRECT_URL setting`:
+
+.. note::
+You can use :func:`~django.core.urlresolvers.reverse_lazy` to reference
+URLs by their name instead of providing a hardcoded value. Assuming a
+``urls.py`` with an URL pattern named ``home``::
+
+urlpatterns = patterns('',
+url('^welcome/$', 'test_app.views.home', name='home'),
+)
+
+You can use :func:`~django.core.urlresolvers.reverse_lazy` like this::
+
+from django.core.urlresolvers import reverse_lazy
+
+LOGIN_REDIRECT_URL = reverse_lazy('home')
+
+This also works fine with localized URLs using
+:func:`~django.conf.urls.i18n.i18n_patterns`.
+
 .. setting:: LOGIN_URL
 
 LOGIN_URL
@@ -1349,6 +1369,9 @@
 The URL where requests are redirected for login, especially when using the
 :func:`~django.contrib.auth.decorators.login_required` decorator.
 
+.. note::
+See the `note on LOGIN_REDIRECT_URL setting`_
+
 .. setting:: LOGOUT_URL
 
 LOGOUT_URL
@@ -1358,6 +1381,9 @@
 
 LOGIN_URL counterpart.
 
+.. note::
+See the `note on LOGIN_REDIRECT_URL setting`_
+
 .. setting:: MANAGERS
 
 MANAGERS

Modified: django/trunk/docs/topics/http/urls.txt
===
--- django/trunk/docs/topics/http/urls.txt  2012-03-02 16:55:56 UTC (rev 
17625)
+++ django/trunk/docs/topics/http/urls.txt  2012-03-02 16:56:04 UTC (rev 
17626)
@@ -888,6 +888,8 @@
 
 A lazily evaluated version of `reverse()`_.
 
+.. function:: reverse_lazy(viewname, [urlconf=None, args=None, kwargs=None, 
current_app=None])
+
 It is useful for when you need to use a URL reversal before your project's
 URLConf is loaded. Some common cases where this function is necessary are:
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r17625 - in django/trunk: django/views/generic tests/regressiontests/generic_views

[noreply]

Author: jezdez
Date: 2012-03-02 08:55:56 -0800 (Fri, 02 Mar 2012)
New Revision: 17625

Modified:
   django/trunk/django/views/generic/base.py
   django/trunk/tests/regressiontests/generic_views/base.py
Log:
Fixed #16842 -- Modified the RedirectView to correctly handle query strings 
with percent symbols. Thanks, accuser, ja...@minilop.net and Claude Paroz.

Modified: django/trunk/django/views/generic/base.py
===
--- django/trunk/django/views/generic/base.py   2012-03-02 16:45:06 UTC (rev 
17624)
+++ django/trunk/django/views/generic/base.py   2012-03-02 16:55:56 UTC (rev 
17625)
@@ -139,12 +139,11 @@
 are provided as kwargs to this method.
 """
 if self.url:
+url = self.url % kwargs
 args = self.request.META.get('QUERY_STRING', '')
 if args and self.query_string:
-url = "%s?%s" % (self.url, args)
-else:
-url = self.url
-return url % kwargs
+url = "%s?%s" % (url, args)
+return url
 else:
 return None
 

Modified: django/trunk/tests/regressiontests/generic_views/base.py
===
--- django/trunk/tests/regressiontests/generic_views/base.py2012-03-02 
16:45:06 UTC (rev 17624)
+++ django/trunk/tests/regressiontests/generic_views/base.py2012-03-02 
16:55:56 UTC (rev 17625)
@@ -283,6 +283,13 @@
 self.assertEqual(response.status_code, 301)
 self.assertEqual(response['Location'], '/bar/?pork=spam')
 
+def test_include_urlencoded_args(self):
+"GET arguments can be URL-encoded when included in the redirected URL"
+response = RedirectView.as_view(url='/bar/', query_string=True)(
+self.rf.get('/foo/?unicode=%E2%9C%93'))
+self.assertEqual(response.status_code, 301)
+self.assertEqual(response['Location'], '/bar/?unicode=%E2%9C%93')
+
 def test_parameter_substitution(self):
 "Redirection URLs can be parameterized"
 response = 
RedirectView.as_view(url='/bar/%(object_id)d/')(self.rf.get('/foo/42/'), 
object_id=42)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16842: RedirectView (class based) query string format bug

[Django]

#16842: RedirectView (class based) query string format bug
-+-
 Reporter:  slafs|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Generic views|  Version:  1.3
 Severity:  Normal   |   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 jezdez):

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


Comment:

 In [17625]:
 {{{
 #!CommitTicketReference repository="" revision="17625"
 Fixed #16842 -- Modified the RedirectView to correctly handle query
 strings with percent symbols. Thanks, accuser, ja...@minilop.net and
 Claude Paroz.
 }}}

-- 
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] r17624 - django/trunk/docs/topics/db

[noreply]

Author: carljm
Date: 2012-03-02 08:45:06 -0800 (Fri, 02 Mar 2012)
New Revision: 17624

Modified:
   django/trunk/docs/topics/db/queries.txt
Log:
Fixed #17794 - Added a bunch of cross-reference links to the DB queries topic 
documentation. Thanks guettli for the initial patch.

Modified: django/trunk/docs/topics/db/queries.txt
===
--- django/trunk/docs/topics/db/queries.txt 2012-03-02 16:06:11 UTC (rev 
17623)
+++ django/trunk/docs/topics/db/queries.txt 2012-03-02 16:45:06 UTC (rev 
17624)
@@ -53,7 +53,7 @@
 class represents a particular record in the database table.
 
 To create an object, instantiate it using keyword arguments to the model class,
-then call ``save()`` to save it to the database.
+then call :meth:`~django.db.models.Model.save` to save it to the database.
 
 You import the model class from wherever it lives on the Python path, as you
 may expect. (We point this out here because previous Django versions required
@@ -66,22 +66,24 @@
 >>> b.save()
 
 This performs an ``INSERT`` SQL statement behind the scenes. Django doesn't hit
-the database until you explicitly call ``save()``.
+the database until you explicitly call :meth:`~django.db.models.Model.save`.
 
-The ``save()`` method has no return value.
+The :meth:`~django.db.models.Model.save` method has no return value.
 
 .. seealso::
 
-``save()`` takes a number of advanced options not described here.
-See the documentation for ``save()`` for complete details.
+:meth:`~django.db.models.Model.save` takes a number of advanced options not
+described here.  See the documentation for
+:meth:`~django.db.models.Model.save` for complete details.
 
-To create an object and save it all in one step see the ``create()``
-method.
+To create an object and save it all in one step see the
+:meth:`~django.db.models.query.QuerySet.create()` method.
 
 Saving changes to objects
 =
 
-To save changes to an object that's already in the database, use ``save()``.
+To save changes to an object that's already in the database, use
+:meth:`~django.db.models.Model.save`.
 
 Given a ``Blog`` instance ``b5`` that has already been saved to the database,
 this example changes its name and updates its record in the database::
@@ -90,14 +92,15 @@
 >> b5.save()
 
 This performs an ``UPDATE`` SQL statement behind the scenes. Django doesn't hit
-the database until you explicitly call ``save()``.
+the database until you explicitly call :meth:`~django.db.models.Model.save`.
 
 Saving ``ForeignKey`` and ``ManyToManyField`` fields
 
 
-Updating a ``ForeignKey`` field works exactly the same way as saving a normal
-field; simply assign an object of the right type to the field in question.
-This example updates the ``blog`` attribute of an ``Entry`` instance 
``entry``::
+Updating a :class:`~django.db.models.ForeignKey` field works exactly the same
+way as saving a normal field; simply assign an object of the right type to the
+field in question.  This example updates the ``blog`` attribute of an ``Entry``
+instance ``entry``::
 
 >>> from blog.models import Entry
 >>> entry = Entry.objects.get(pk=1)
@@ -105,16 +108,19 @@
 >>> entry.blog = cheese_blog
 >>> entry.save()
 
-Updating a ``ManyToManyField`` works a little differently; use the ``add()``
-method on the field to add a record to the relation. This example adds the
-``Author`` instance ``joe`` to the ``entry`` object::
+Updating a :class:`~django.db.models.ManyToManyField` works a little
+differently; use the
+:meth:`~django.db.models.fields.related.RelatedManager.add` method on the field
+to add a record to the relation. This example adds the ``Author`` instance
+``joe`` to the ``entry`` object::
 
 >>> from blog.models import Author
 >>> joe = Author.objects.create(name="Joe")
 >>> entry.authors.add(joe)
 
-To add multiple records to a ``ManyToManyField`` in one go, include multiple
-arguments in the call to ``add()``, like this::
+To add multiple records to a :class:`~django.db.models.ManyToManyField` in one
+go, include multiple arguments in the call to
+:meth:`~django.db.models.fields.related.RelatedManager.add`, like this::
 
 >>> john = Author.objects.create(name="John")
 >>> paul = Author.objects.create(name="Paul")
@@ -127,17 +133,20 @@
 Retrieving objects
 ==
 
-To retrieve objects from your database, you construct a ``QuerySet`` via a
-``Manager`` on your model class.
+To retrieve objects from your database, you construct a
+:class:`~django.db.models.query.QuerySet` via a
+:class:`~django.db.models.Manager` on your model class.
 
-A ``QuerySet`` represents a collection of objects from your database. It can
-have zero, one or many *filters* -- criteria that narrow down the collection
-based on given parameters. In SQL terms, a ``QuerySet`` equates to a ``SELECT``
-statement, 

Re: [Django] #17794: Docs should have more links to reference

[Django]

#17794: Docs should have more links to reference
--+
 Reporter:  guettli   |Owner:  guettli
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.3
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by carljm):

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


Comment:

 In [17624]:
 {{{
 #!CommitTicketReference repository="" revision="17624"
 Fixed #17794 - Added a bunch of cross-reference links to the DB queries
 topic documentation. Thanks guettli for the initial patch.
 }}}

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

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

Re: [Django] #17794: Docs should have more links to reference

[Django]

#17794: Docs should have more links to reference
--+
 Reporter:  guettli   |Owner:  guettli
 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):

 * stage:  Ready for checkin => Accepted


Comment:

 Please do not mark your own patches as 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] #17793: SimpleTepmlateResponse is not re-picklable

[Django]

#17793: SimpleTepmlateResponse is not re-picklable
-+--
 Reporter:  ironfroggy   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.3
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by carljm):

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


Comment:

 Thanks for the report - duplicate of #16326 (which is, happily, already
 fixed in 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] #14039: FileField special-casing breaks MultiValueField including a FileField

[Django]

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

 * cc: mail@… (added)


Comment:

 I was thinking about working on documentation for it, but I'm not sure
 where to start, and, first of all, why changes to the documentation are
 needed at all.

 For me it seems like this change concerns itself with lower-level API and
 so does only matter for someone who is working on a custom form Field. But
 this topic isn't documented at all at the moment, so there's just no
 documentation to be updated.

 Please correct me if I'm wrong.

-- 
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
-+-
Changes (by carljm):

 * severity:  Normal => Release blocker


Comment:

 Actually, marking it a release blocker because at the very least it needs
 a doc fix before release; an actual fix is not a release blocker but would
 be nice. Thanks claudep for pointing this out.

-- 
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] #17790: Ajax CSRF example is needlessly restrictive

[Django]

#17790: Ajax CSRF example is needlessly restrictive
+
 Reporter:  jonathan.hayward@…  |  Owner:  nobody
 Type:  Bug | Status:  closed
Component:  Documentation   |Version:  1.3
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  1
UI/UX:  0   |
+
Changes (by carljm):

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


Comment:

 In [17623]:
 {{{
 #!CommitTicketReference repository="" revision="17623"
 Fixed #17790 - Made the Ajax CSRF jQuery example work with jQuery in
 compatibility mode, too. Thanks Jonathan Hayward for the suggestion.
 }}}

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

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

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

[noreply]

Author: carljm
Date: 2012-03-02 08:06:11 -0800 (Fri, 02 Mar 2012)
New Revision: 17623

Modified:
   django/trunk/docs/ref/contrib/csrf.txt
Log:
Fixed #17790 - Made the Ajax CSRF jQuery example work with jQuery in 
compatibility mode, too. Thanks Jonathan Hayward for the suggestion.

Modified: django/trunk/docs/ref/contrib/csrf.txt
===
--- django/trunk/docs/ref/contrib/csrf.txt  2012-03-02 11:29:14 UTC (rev 
17622)
+++ django/trunk/docs/ref/contrib/csrf.txt  2012-03-02 16:06:11 UTC (rev 
17623)
@@ -91,7 +91,7 @@
 
 .. code-block:: javascript
 
-$(document).ajaxSend(function(event, xhr, settings) {
+jQuery(document).ajaxSend(function(event, xhr, settings) {
 function getCookie(name) {
 var cookieValue = null;
 if (document.cookie && document.cookie != '') {

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
-+-
 Reporter:  mtredinnick  |Owner:
 Type:  Bug  |  mtredinnick
Component:  Database layer   |   Status:  new
  (models, ORM)  |  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
-+-
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.

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:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by carljm):

 Talked this over briefly with Jacob in IRC - it's not a release blocker,
 since it seems likely that the answer "use a better database" suffices to
 prevent it being an actual problem in production (except maybe in Oracle?
 not clear to me). I'd still like to get it fixed for 1.4 if we can, and
 something like a `bulk_insert_chunk_size` on the db backend seems pretty
 reasonable.

-- 
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] #15124: BooleanField should not use False as default (unless provided)

[Django]

#15124: BooleanField should not use False as default (unless provided)
-+-
 Reporter:  andrewbadr   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-alpha-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
-+-

Comment (by carljm):

 My take here is that this is a legitimate bugfix and should go in, but
 there's enough potential for breakage of existing code that I'm hesitant
 to drop it in after the beta, I'd rather target it for 1.5 at this point.

-- 
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] #17785: PostgreSQL Introspection: get_relations() broken after drop column

[Django]

#17785: PostgreSQL Introspection: get_relations() broken after drop column
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  psycopg2 |  Needs documentation:  0
  introspection  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by carljm):

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


Comment:

 Off-hand I don't see any reason why this fix deserves to not be tested. I
 realize that the test will require creating and modifying a table, but
 that's not a problem, the existing introspection tests already use raw SQL
 for this sort of thing, it's not difficult.

-- 
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] #16173: manager.get on foreign key fields (related fields)

[Django]

#16173: manager.get on foreign key fields (related fields)
-+-
 Reporter:  nitinbhide@… |Owner:  tobias
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Database layer   |   Resolution:  wontfix
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  manager foreignkey   |  Patch needs improvement:  1
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by carljm):

 * status:  assigned => closed
 * needs_better_patch:  0 => 1
 * resolution:   => wontfix


Comment:

 Replying to [comment:8 nitinbhide@…]:
 > Check the line,
 > {{{
 > rel_obj = rel_mgr.using(db).get(**params).
 > }}}

 This line of code no longer exists in trunk Django, the code has been
 rearranged in a way that makes this change more difficult
 (`ReverseSingleRelatedObjectDescriptor` now has a `get_query_set` method,
 which would have to be changed to `get_manager`).

 I'm not convinced that it's reasonable to even expect the related
 manager's `get()` method to be called here; `get()` is one of the many
 Manager methods that is simply a pass-through to `QuerySet`, and I think
 it would be a mistake for Django to try to start providing guarantees of
 when the pass-through Manager method is called vs the same method on the
 Manager's queryset. If you want to override reliably, you need to override
 the lower-level `get_query_set` method on the Manager and provide a custom
 `QuerySet` class with your `get` functionality.

 Closing wontfix.

-- 
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] #17794: Docs should have more links to reference

[Django]

#17794: Docs should have more links to reference
-+-
 Reporter:  guettli  |Owner:  guettli
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by guettli):

 * has_patch:  0 => 1
 * easy:  0 => 1
 * stage:  Unreviewed => Ready for checkin


Comment:

 I updated this file: docs/topics/db/queries.txt

-- 
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] #16188: Added locale formats for swiss german language

[Django]

#16188: Added locale formats for swiss german language
-+-
 Reporter:  sspross  |Owner:  ojii
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:   |   Resolution:  fixed
  Internationalization   | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:  locale, formats  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by jezdez):

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


-- 
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] #16188: Added locale formats for swiss german language

[Django]

#16188: Added locale formats for swiss german language
-+-
 Reporter:  sspross  |Owner:  ojii
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:   |   Resolution:
  Internationalization   | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:  locale, formats  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by jezdez):

 This was accidentally committed with a faulty commit message due to PEBKAC
 in r17472.

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

[Django]

#17814: RELATED_NAME_OVERRIDES
--+
 Reporter:  yanchenko.igor@…  |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 I use external apps with same name models (for example it's forum.post and
 blog.post) and have conflict with related_name, both have
  user = models.!ForeignKey(User, related_name="posts")

 I writed patch with principle like ABSOLUTE_URL_OVERRIDES

-- 
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] #17813: Implement an opposite method for Entry.objects.latest

[Django]

#17813: Implement an opposite method for Entry.objects.latest
--+
 Reporter:  tonnzor   |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 At the moment we have '''`Entry.objects.latest`''' method that efficiently
 gets the last entry in queryset
 [https://docs.djangoproject.com/en/dev/ref/models/querysets/#latest]

 We need another handy method that would do the same but getting the first
 element.

 I suggest to name it '''`first`''' or something like that.

 I have attached a sample patch.

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

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

Re: [Django] #17806: CachedFilesMixin url_converter doesn't handle absolute paths correctly

[Django]

#17806: CachedFilesMixin url_converter doesn't handle absolute paths correctly
-+-
 Reporter:  lpetre   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-
Changes (by jezdez):

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


Comment:

 In [17622]:
 {{{
 #!CommitTicketReference repository="" revision="17622"
 Fixed #17806 -- Fixed off-by-n error in the CachedStaticFilesStorage that
 prevented it from finding files in nested directories. Many thanks to
 lpetre.
 }}}

-- 
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] r17622 - in django/trunk: django/contrib/staticfiles tests/regressiontests/staticfiles_tests tests/regressiontests/staticfiles_tests/project/documents/cached

[noreply]

Author: jezdez
Date: 2012-03-02 03:29:14 -0800 (Fri, 02 Mar 2012)
New Revision: 17622

Modified:
   django/trunk/django/contrib/staticfiles/storage.py
   
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/absolute.css
   django/trunk/tests/regressiontests/staticfiles_tests/tests.py
Log:
Fixed #17806 -- Fixed off-by-n error in the CachedStaticFilesStorage that 
prevented it from finding files in nested directories. Many thanks to lpetre.

Modified: django/trunk/django/contrib/staticfiles/storage.py
===
--- django/trunk/django/contrib/staticfiles/storage.py  2012-03-02 11:07:36 UTC 
(rev 17621)
+++ django/trunk/django/contrib/staticfiles/storage.py  2012-03-02 11:29:14 UTC 
(rev 17622)
@@ -160,7 +160,7 @@
 if sub_level:
 if sub_level == 1:
 parent_level -= 1
-start, end = parent_level, sub_level - 1
+start, end = parent_level, 1
 else:
 start, end = 1, sub_level - 1
 joined_result = '/'.join(name_parts[:-start] + url_parts[end:])

Modified: 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/absolute.css
===
--- 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/absolute.css
  2012-03-02 11:07:36 UTC (rev 17621)
+++ 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/absolute.css
  2012-03-02 11:29:14 UTC (rev 17622)
@@ -1 +1,4 @@
 @import url("/static/cached/styles.css");
+body {
+background: #d3d6d8 url(/static/cached/img/relative.png);
+}
\ No newline at end of file

Modified: django/trunk/tests/regressiontests/staticfiles_tests/tests.py
===
--- django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2012-03-02 11:07:36 UTC (rev 17621)
+++ django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2012-03-02 11:29:14 UTC (rev 17622)
@@ -416,11 +416,12 @@
 
 def test_template_tag_absolute(self):
 relpath = self.cached_file_path("cached/absolute.css")
-self.assertEqual(relpath, "cached/absolute.cc80cb5e2eb1.css")
+self.assertEqual(relpath, "cached/absolute.23f087ad823a.css")
 with storage.staticfiles_storage.open(relpath) as relfile:
 content = relfile.read()
 self.assertNotIn("/static/cached/styles.css", content)
 self.assertIn("/static/cached/styles.93b1147e8552.css", content)
+self.assertIn('/static/cached/img/relative.acae32e4532b.png', 
content)
 
 def test_template_tag_denorm(self):
 relpath = self.cached_file_path("cached/denorm.css")

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #17734: 302 redirect to standard language for non-i18n URL's when returning 404.

[Django]

#17734: 302 redirect to standard language for non-i18n URL's when returning 404.
--+
 Reporter:  petar@…   |Owner:  jezdez
 Type:  Bug   |   Status:  closed
Component:  Internationalization  |  Version:  SVN
 Severity:  Release blocker   |   Resolution:  fixed
 Keywords:  urlconf, i18n | 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:  new => closed
 * resolution:   => fixed


Comment:

 In [17621]:
 {{{
 #!CommitTicketReference repository="" revision="17621"
 Fixed #17734 -- Made sure to only redirect translated URLs if they can
 actually be resolved to prevent unwanted redirects. Many thanks to Orne
 Brocaar and Anssi Kääriäinen for input.
 }}}

-- 
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] r17621 - in django/trunk: django/core django/middleware tests/regressiontests/i18n/patterns tests/regressiontests/i18n/patterns/urls

[noreply]

Author: jezdez
Date: 2012-03-02 03:07:36 -0800 (Fri, 02 Mar 2012)
New Revision: 17621

Modified:
   django/trunk/django/core/urlresolvers.py
   django/trunk/django/middleware/common.py
   django/trunk/django/middleware/locale.py
   django/trunk/tests/regressiontests/i18n/patterns/tests.py
   django/trunk/tests/regressiontests/i18n/patterns/urls/namespace.py
Log:
Fixed #17734 -- Made sure to only redirect translated URLs if they can actually 
be resolved to prevent unwanted redirects. Many thanks to Orne Brocaar and 
Anssi K?\195?\164?\195?\164ri?\195?\164inen for input.

Modified: django/trunk/django/core/urlresolvers.py
===
--- django/trunk/django/core/urlresolvers.py2012-03-02 05:03:52 UTC (rev 
17620)
+++ django/trunk/django/core/urlresolvers.py2012-03-02 11:07:36 UTC (rev 
17621)
@@ -518,3 +518,17 @@
 changed from the default one.
 """
 return getattr(_urlconfs, "value", default)
+
+def is_valid_path(path, urlconf=None):
+"""
+Returns True if the given path resolves against the default URL resolver,
+False otherwise.
+
+This is a convenience method to make working with "is this a match?" cases
+easier, avoiding unnecessarily indented try...except blocks.
+"""
+try:
+resolve(path, urlconf)
+return True
+except Resolver404:
+return False

Modified: django/trunk/django/middleware/common.py
===
--- django/trunk/django/middleware/common.py2012-03-02 05:03:52 UTC (rev 
17620)
+++ django/trunk/django/middleware/common.py2012-03-02 11:07:36 UTC (rev 
17621)
@@ -64,8 +64,8 @@
 # trailing slash and there is no pattern for the current path
 if settings.APPEND_SLASH and (not old_url[1].endswith('/')):
 urlconf = getattr(request, 'urlconf', None)
-if (not _is_valid_path(request.path_info, urlconf) and
-_is_valid_path("%s/" % request.path_info, urlconf)):
+if (not urlresolvers.is_valid_path(request.path_info, urlconf) and
+urlresolvers.is_valid_path("%s/" % request.path_info, 
urlconf)):
 new_url[1] = new_url[1] + '/'
 if settings.DEBUG and request.method == 'POST':
 raise RuntimeError((""
@@ -151,18 +151,3 @@
 """
 # Different subdomains are treated as different domains.
 return referer is not None and re.match("^https?://%s/" % 
re.escape(domain), referer)
-
-def _is_valid_path(path, urlconf=None):
-"""
-Returns True if the given path resolves against the default URL resolver,
-False otherwise.
-
-This is a convenience method to make working with "is this a match?" cases
-easier, avoiding unnecessarily indented try...except blocks.
-"""
-try:
-urlresolvers.resolve(path, urlconf)
-return True
-except urlresolvers.Resolver404:
-return False
-

Modified: django/trunk/django/middleware/locale.py
===
--- django/trunk/django/middleware/locale.py2012-03-02 05:03:52 UTC (rev 
17620)
+++ django/trunk/django/middleware/locale.py2012-03-02 11:07:36 UTC (rev 
17621)
@@ -1,10 +1,13 @@
 "This is the locale selecting middleware that will look at accept headers"
 
-from django.core.urlresolvers import get_resolver, LocaleRegexURLResolver
+from django.conf import settings
+from django.core.urlresolvers import (is_valid_path, get_resolver,
+  LocaleRegexURLResolver)
 from django.http import HttpResponseRedirect
 from django.utils.cache import patch_vary_headers
 from django.utils import translation
 
+
 class LocaleMiddleware(object):
 """
 This is a very simple middleware that parses a request
@@ -23,13 +26,17 @@
 
 def process_response(self, request, response):
 language = translation.get_language()
-translation.deactivate()
-
 if (response.status_code == 404 and
 not translation.get_language_from_path(request.path_info)
 and self.is_language_prefix_patterns_used()):
-return HttpResponseRedirect(
-'/%s%s' % (language, request.get_full_path()))
+urlconf = getattr(request, 'urlconf', None)
+language_path = '/%s%s' % (language, request.path_info)
+if settings.APPEND_SLASH and not language_path.endswith('/'):
+language_path = language_path + '/'
+if is_valid_path(language_path, urlconf):
+return HttpResponseRedirect(
+'/%s%s' % (language, request.get_full_path()))
+translation.deactivate()
 
 patch_vary_headers(response, ('Accept-Language',))
 if 'Content-Language' not in response:

Modified: django/trunk/tests/regressiontests/i18n/patterns/tests.py

Re: [Django] #17734: 302 redirect to standard language for non-i18n URL's when returning 404.

[Django]

#17734: 302 redirect to standard language for non-i18n URL's when returning 404.
--+
 Reporter:  petar@…   |Owner:  jezdez
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  SVN
 Severity:  Release blocker   |   Resolution:
 Keywords:  urlconf, i18n | 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):

 * 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] #17812: Symlink link to media files is deleted after calling of delete method of ImageField if value of it field is None.

[Django]

#17812: Symlink link to media files is deleted after calling of delete method of
ImageField if value of it field is None.
-+-
 Reporter:  piterimov@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  File |  Version:  1.3
  uploads/storage|   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 anonymous):

 * needs_docs:   => 0
 * component:  Uncategorized => File uploads/storage
 * needs_tests:   => 0
 * needs_better_patch:   => 0


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

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

[Django] #17812: Symlink link to media files is deleted after calling of delete method of ImageField if value of it field is None.

[Django]

#17812: Symlink link to media files is deleted after calling of delete method of
ImageField if value of it field is None.
---+
 Reporter:  piterimov@…|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 If media folder for media files is symlink then after calling of delete
 method of {{{ ImageField }}} model's field this symbolic link has been
 deleted if value of this field is None (i. e. value of {{{
 image_field.name }}} is empty).
 This was found for django 1.3.1 (but maybe and is for others). This is
 happening for {{{ ImageField }}} only. {{{ FileField }}} works good.

-- 
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] #17753: Internationalizing URL Patterns Redirect should be 404

[Django]

#17753: Internationalizing URL Patterns Redirect should be 404
-+-
 Reporter:  jaddison |Owner:  jezdez
 Type:  Bug  |   Status:  new
Component:   |  Version:
  Internationalization   |  1.4-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:  url patterns,| Triage Stage:  Accepted
  internationalization   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by jezdez):

 * severity:  Release blocker => Normal
 * stage:  Unreviewed => Accepted


Comment:

 While this is certainly an odd situation, we really can't do something
 about this at this stage of the release cycle. It **is** technical correct
 to redirect to /en/de/ if German isn't listed in the list of languages.

 This may be fixed by also checking the global list of languages supported
 by Django, but this will again break if a language is tried that Django
 itself doesn't support. Introducing a setting just to handle this case
 seems like a bad idea, too.

 The suggestion to make this error handling pluggable seems like a good
 idea at first, too, but then I realized that we only provide this kind of
 extensibility for specific HTTP level errors, e.g. handler404, handler500
 etc. I'm at loss how we could convince ourselves to make an exception for
 this use case.

 That said, I'm accepting this ticket as a limitation of the current
 implementation but remove the release blocker label.

-- 
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] #17806: CachedFilesMixin url_converter doesn't handle absolute paths correctly

[Django]

#17806: CachedFilesMixin url_converter doesn't handle absolute paths correctly
-+-
 Reporter:  lpetre   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-
Changes (by lpetre):

 * needs_docs:   => 0
 * has_patch:  0 => 1
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * needs_better_patch:   => 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.

[Django] #17811: Connection object is no passed to the EmailMessage constructor when called from send_mass_mail

[Django]

#17811: Connection object is no passed to the EmailMessage constructor when 
called
from send_mass_mail
-+-
 Reporter:  fed239   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (Mail)  |Version:  1.3
 Severity:  Normal   |   Keywords:  mail, connection, email
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 There is a difference in the behavior of send_mail and send_mass_mail
 function. send_mail passes connection as a parameter to the EmailMessage
 constructor and send_mass_mail does not.
 {{{
 44  def send_mail(subject, message, from_email, recipient_list,
 45fail_silently=False, auth_user=None,
 auth_password=None,
 46connection=None):
 ...
 57  connection = connection or get_connection(username=auth_user,
 58  password=auth_password,
 59  fail_silently=fail_silently)
 60  return EmailMessage(subject, message, from_email,
 recipient_list,
 61  connection=connection).send()
 }}}

 {{{
 64  def send_mass_mail(datatuple, fail_silently=False, auth_user=None,
 65 auth_password=None, connection=None):
 ...
 78  connection = connection or get_connection(username=auth_user,
 79  password=auth_password,
 80  fail_silently=fail_silently)
 81  messages = [EmailMessage(subject, message, sender, recipient)
 82  for subject, message, sender, recipient in
 datatuple]
 83  return connection.send_messages(messages)
 }}}

 This causes troubles if email backend stores something inside the self
 object for the later use and expects that messages would have reference to
 it.

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

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

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
+--
Changes (by claudep):

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


Comment:

 I tried to reproduce with 1.3 and 1.4 code, but with no luck. So I suggest
 you dig a little more to see what's happening. Check also in the Django
 admin interface if the label/help text are showing correctly for
 account_type field.

-- 
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] #17810: Switching from cookie-based sessions to memcached-based sessions raises exception

[Django]

#17810: Switching from cookie-based sessions to memcached-based sessions raises
exception
--+--
 Reporter:  gabrielhurley |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.4-beta-1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by jezdez):

 * severity:  Release blocker => Normal


Comment:

 This is exactly that: "arbitrarily switching session backends isn't
 generally supported behavior". Removing the release blocker again.

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