date:20110823

Re: [Django] #16686: Race condition in test_view_decorator()

2011-08-23 Thread Django

#16686: Race condition in test_view_decorator()
--+---
   Reporter:  barry@… |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
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   |
--+---

Comment (by mtredinnick):

 I noticed yesterday that the CI install at http://ci.django-
 cms.org/job/Django/ was showing sporadic failures in the same area of
 tests. They were inconsistent, indicating there is something race-y going
 on there with timings, but my initial read didn't show up what it was.

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

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

Re: [Django] #16586: Use Sphinx' intersphinx extension to link to Python docs

2011-08-23 Thread Django

#16586: Use Sphinx' intersphinx extension to link to Python docs
-+-
   Reporter:  jezdez |  Owner:  aaugustin
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by DrMeers):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 Thanks for the patch Aymeric. I was about to check it in when I discovered
 some links don't render correctly; e.g.:

 "To get started contributing, you’ll want to read the reStructuredText
 Primer . After that, you’ll want to read about the Sphinx-
 specific markup  that’s used to manage metadata, indexing,
 and cross-references."

 -- actually rendered like that. Others (e.g. peps) seems to work fine. Am
 I missing some configuration to fix these ones, or is the syntax
 incorrect?

 Also, do we care that the links render as displayed in the uploaded
 screenshot? (which I've confirmed locally).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #6045: Many2Many manager and “TypeError: filter() keywords must be strings”

2011-08-23 Thread Django

#6045: Many2Many manager and “TypeError: filter() keywords must be strings”
-+-
   Reporter:  proxor |  Owner:  Natim
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution:  fixed  |   Severity:  Normal
   Triage Stage:  Ready for  |   Keywords:  many2many, related,
  checkin|  unicode easy-pickings
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  1
-+-
Changes (by mtredinnick):

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


Comment:

 This was effectively fixed by r16663, in a slightly different way. I added
 the test from the latest patch here as a safety net.

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

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

[Changeset] r16679 - django/trunk/tests/modeltests/m2m_and_m2o

2011-08-23 Thread noreply

Author: mtredinnick
Date: 2011-08-23 20:51:33 -0700 (Tue, 23 Aug 2011)
New Revision: 16679

Modified:
   django/trunk/tests/modeltests/m2m_and_m2o/models.py
   django/trunk/tests/modeltests/m2m_and_m2o/tests.py
Log:
Added another test to confirm fix in r16663.

This is the test case from #6045, which was fixed by the above commit.
Refs #6045, #16299

Modified: django/trunk/tests/modeltests/m2m_and_m2o/models.py
===
--- django/trunk/tests/modeltests/m2m_and_m2o/models.py 2011-08-23 23:43:29 UTC 
(rev 16678)
+++ django/trunk/tests/modeltests/m2m_and_m2o/models.py 2011-08-24 03:51:33 UTC 
(rev 16679)
@@ -19,3 +19,7 @@
 
 class Meta:
 ordering = ('num',)
+
+class UnicodeReferenceModel(models.Model): 
+others = models.ManyToManyField(u"UnicodeReferenceModel") 
+

Modified: django/trunk/tests/modeltests/m2m_and_m2o/tests.py
===
--- django/trunk/tests/modeltests/m2m_and_m2o/tests.py  2011-08-23 23:43:29 UTC 
(rev 16678)
+++ django/trunk/tests/modeltests/m2m_and_m2o/tests.py  2011-08-24 03:51:33 UTC 
(rev 16679)
@@ -1,7 +1,7 @@
 from django.db.models import Q
 from django.test import TestCase
 
-from models import Issue, User
+from models import Issue, User, UnicodeReferenceModel
 
 
 class RelatedObjectTests(TestCase):
@@ -73,3 +73,16 @@
 ],
 lambda i: i.num
 )
+
+class RelatedObjectTests(TestCase): 
+def test_m2m_with_unicode_reference(self): 
+"""
+Regression test for #6045: references to other models can be unicode
+strings, providing they are directly convertible to ASCII.
+"""
+m1=UnicodeReferenceModel.objects.create() 
+m2=UnicodeReferenceModel.objects.create() 
+m2.others.add(m1) # used to cause an error (see ticket #6045) 
+m2.save() 
+list(m2.others.all()) # Force retrieval.
+

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #6045: Many2Many manager and “TypeError: filter() keywords must be strings”

2011-08-23 Thread Django

#6045: Many2Many manager and “TypeError: filter() keywords must be strings”
-+-
   Reporter:  proxor |  Owner:  Natim
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Ready for  |   Keywords:  many2many, related,
  checkin|  unicode easy-pickings
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  1
-+-

Comment (by mtredinnick):

 In [16679]:
 {{{
 #!CommitTicketReference repository="" revision="16679"
 Added another test to confirm fix in r16663.

 This is the test case from #6045, which was fixed by the above commit.
 Refs #6045, #16299
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16299: Django model-module doesn't support unicode_literals

2011-08-23 Thread Django

#16299: Django model-module doesn't support unicode_literals
-+-
   Reporter: |  Owner:  nobody
  martijn.bastiaan@… | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:  unicode,
   Triage Stage:  Accepted   |  ForeignKey, AttributeError
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  1
-+-

Comment (by mtredinnick):

 In [16679]:
 {{{
 #!CommitTicketReference repository="" revision="16679"
 Added another test to confirm fix in r16663.

 This is the test case from #6045, which was fixed by the above commit.
 Refs #6045, #16299
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #7231: New "join" parameter for the "extra" QuerySet method

2011-08-23 Thread Django

#7231: New "join" parameter for the "extra" QuerySet method
-+-
   Reporter:  Davide |  Owner:  nobody
  "Design" Muzzarelli| Status:  closed
   Type: |  Component:  Database layer
  Uncategorized  |  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  queryset extra left
 Resolution:  wontfix|  join
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  1
Needs documentation:  1  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by mrmachine):

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


Comment:

 I can't reply to the discussion linked on Google Groups anymore, but
 wanted to add my comment that I have found many uses for `.extra()` and
 also hit the limitation of being unable to add left outer joins to a query
 generated by the ORM. I would not like to see it disappear in favour of
 raw SQL.

 My current use case is for joining reverse generic relations on queries
 against a model that does not have a `GenericRelation` field back to the
 generic model (because I don't know which models it will be used with -- I
 can't add models to 3rd party code).

 To require the whole query in raw SQL in order to join generic relations
 would mitigate the pluggability of the generic model in question.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16687: Several tests requiring internet fail on Ubuntu build machines

2011-08-23 Thread Django

#16687: Several tests requiring internet fail on Ubuntu build machines
+---
   Reporter:  barry@…   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Testing framework
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---

Comment (by ramiro):

 Actually, we've solved this in trunk (see #16189 and [16451]. I haven't
 backported that to the 1.3.X (actually I'm not backporting anything except
 fixes for regressions introduced in the 1.3 development cycle).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16687: Several tests requiring internet fail on Ubuntu build machines

2011-08-23 Thread Django

#16687: Several tests requiring internet fail on Ubuntu build machines
+---
   Reporter:  barry@…   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Testing framework
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by russellm):

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


Comment:

 Yes, there are better ways -- we can and do use the @skipUnless and
 @skipIf decorators, and we use mock services when possible. In this case,
 nobody has got around to providing a patch that either skips/expected
 fails the test when there's no network connection, or provides a mock for
 urllib (or whatever needs to be mocked in this case).

 A patch to do either of these would certainly be welcome; I'd probably
 prefer a mock to a skipped test, but I could live with either if a mock
 turns out to be too hard to achieve.

 Also - this is the second report (c.f. #16686) where you've referred to
 "the" Ubuntu build machines. Which build machines are you referring to
 here?

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

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

Re: [Django] #16686: Race condition in test_view_decorator()

2011-08-23 Thread Django

#16686: Race condition in test_view_decorator()
--+---
   Reporter:  barry@… |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
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 russellm):

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


Comment:

 Is this actually a race condition, or just an issue of being a bit more
 acommodating with timings?  The test sets up the "other" cache with a 1
 second expiry; the test has a 2 second sleep (line 1452) to make sure that
 it expires. There is a second sleep at line 1488; the final test you
 report is of a view with a 4 second timeout. This might be a bit of a
 lineball check -- technically, (2x2seconds + time to run other tests)
 should be > 4 seconds, but on a fast box, it might not evaluate like that.
 A 3 second sleep at line 1452 should be enough to ensure that the 4 second
 cache has expires (2 + 3 second sleep).

 So - if I've understood the problem here, it isn't a race condition --
 just a case where a fast box exposes the fact that 2+2+time for extra work
 may not be enough time to see the cache expire for the last test.

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

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

2011-08-23 Thread noreply

Author: mtredinnick
Date: 2011-08-23 16:43:29 -0700 (Tue, 23 Aug 2011)
New Revision: 16678

Modified:
   django/trunk/django/core/management/validation.py
   django/trunk/tests/modeltests/invalid_models/invalid_models/models.py
Log:
Teach "django-admin.py validate" to forbid nullable primary keys.

Fixes #15884, with thanks to JustinTArthur and Julie Pichon.

Modified: django/trunk/django/core/management/validation.py
===
--- django/trunk/django/core/management/validation.py   2011-08-23 15:57:19 UTC 
(rev 16677)
+++ django/trunk/django/core/management/validation.py   2011-08-23 23:43:29 UTC 
(rev 16678)
@@ -39,6 +39,8 @@
 e.add(opts, '"%s": You can\'t use "id" as a field name, 
because each model automatically gets an "id" field if none of the fields have 
primary_key=True. You need to either remove/rename your "id" field or add 
primary_key=True to a field.' % f.name)
 if f.name.endswith('_'):
 e.add(opts, '"%s": Field names cannot end with underscores, 
because this would lead to ambiguous queryset filters.' % f.name)
+if f.primary_key and f.null:
+e.add(opts, '"%s": Primary key fields cannot have null=True.' 
% f.name)
 if isinstance(f, models.CharField):
 try:
 max_length = int(f.max_length)

Modified: django/trunk/tests/modeltests/invalid_models/invalid_models/models.py
===
--- django/trunk/tests/modeltests/invalid_models/invalid_models/models.py   
2011-08-23 15:57:19 UTC (rev 16677)
+++ django/trunk/tests/modeltests/invalid_models/invalid_models/models.py   
2011-08-23 23:43:29 UTC (rev 16678)
@@ -220,7 +220,8 @@
 fk = models.ForeignKey('self', on_delete=models.SET_DEFAULT)
 
 class UnicodeForeignKeys(models.Model):
-"""Foreign keys which can translate to ascii should be OK, but fail if 
they're not."""
+"""Foreign keys which can translate to ascii should be OK, but fail if
+they're not."""
 good = models.ForeignKey(u'FKTarget')
 also_good = models.ManyToManyField(u'FKTarget', related_name='unicode2')
 
@@ -228,7 +229,10 @@
 # when adding the errors in core/management/validation.py
 #bad = models.ForeignKey(u'★')
 
+class PrimaryKeyNull(models.Model):
+my_pk_field = models.IntegerField(primary_key=True, null=True)
 
+
 model_errors = """invalid_models.fielderrors: "charfield": CharFields require 
a "max_length" attribute that is a positive integer.
 invalid_models.fielderrors: "charfield2": CharFields require a "max_length" 
attribute that is a positive integer.
 invalid_models.fielderrors: "charfield3": CharFields require a "max_length" 
attribute that is a positive integer.
@@ -338,4 +342,5 @@
 invalid_models.nonexistingorderingwithsingleunderscore: "ordering" refers to 
"does_not_exist", a field that doesn't exist.
 invalid_models.invalidsetnull: 'fk' specifies on_delete=SET_NULL, but cannot 
be null.
 invalid_models.invalidsetdefault: 'fk' specifies on_delete=SET_DEFAULT, but 
has no default value.
+invalid_models.primarykeynull: "my_pk_field": Primary key fields cannot have 
null=True.
 """

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15884: Model validation allows nullable primary key field.

2011-08-23 Thread Django

#15884: Model validation allows nullable primary key field.
-+-
   Reporter: |  Owner:  JustinTArthur
  JustinTArthur  | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
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 mtredinnick):

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


Comment:

 In [16678]:
 {{{
 #!CommitTicketReference repository="" revision="16678"
 Teach "django-admin.py validate" to forbid nullable primary keys.

 Fixes #15884, with thanks to JustinTArthur and Julie Pichon.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #13906: REPEATABLE READ (as used by default on MySQL) breaks atleast QuerySet.get_or_create().

2011-08-23 Thread Django

#13906: REPEATABLE READ (as used by default on MySQL) breaks atleast
QuerySet.get_or_create().
-+-
   Reporter: |  Owner:
  sebastian_noack| Status:  new
   Type: |  Component:  Database layer
  Cleanup/optimization   |  (models, ORM)
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:  mysql transaction
 Resolution: |  isolation
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by dgouldin):

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

[Django] #16688: unionagg doesn't respect limits

2011-08-23 Thread Django

#16688: unionagg doesn't respect limits
-+
 Reporter:  arc   |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  GIS
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+
 When specifying a limit with slice syntax and then running unionagg, this
 limit is not taken into account. In the below example, unionagg is run on
 the entire set of records rather than only 10 records as expected:


 {{{
 qs = Model.objects.all()[:10]
 ua = qs.unionagg()
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16687: Several tests requiring internet fail on Ubuntu build machines

2011-08-23 Thread Django

#16687: Several tests requiring internet fail on Ubuntu build machines
-+---
 Reporter:  barry@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Testing framework
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+---
 The following tests which require internet connection fail on the Ubuntu
 build machines.  I've commented them out so that django can be built for
 Ubuntu.  There should probably a better way to skip them when there's no
 internet, or write them so that external access isn't required.

 * test_urlfield_3
 * test_urlfield_4
 * test_correct_url_value_passes

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

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

2011-08-23 Thread Django

#16686: Race condition in test_view_decorator()
-+---
 Reporter:  barry@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Testing framework
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+---
 test_view_decorator has this at the bottom:


 # And if we wait a few more seconds
 time.sleep(5)

 # the custom timeouot cache will miss
 response = other_with_timeout_view(request, '18')
 self.assertEqual(response.content, 'Hello World 18')


 This fails on the Ubuntu build machines, although it succeeds on local
 builds.  I got it to pass by bumping up the sleep to 5 seconds, but that's
 just a bandaid.

 Judging from other sleeps in this test, I suspect there are more race
 conditions lurking.

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

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

2011-08-23 Thread Django

#16667: Error in Pagination-Template?
-+---
   Reporter:  Aufwind|  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution:  invalid|   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---

Comment (by anonymous):

 I wasn't aware of that. Thanks 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] #15178: Development server hangs very often when used with IE9 beta

2011-08-23 Thread Django

#15178: Development server hangs very often when used with IE9 beta
-+-
   Reporter: |  Owner:  nobody
  cataliniacob   | Status:  closed
   Type: |  Component:  Core (Other)
  Uncategorized  |   Severity:  Normal
  Milestone: |   Keywords:  ie9 development-
Version:  1.3-beta   |  server
 Resolution: |  Has patch:  0
  worksforme |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by cataliniacob):

 Replying to [comment:8 PaulM]:
 > I'd be willing to bet that this issue (at least some incarnations of it)
 may be due to the single-threaded nature of the dev server in the current
 stable versions of Django.
 > The new multithreaded dev client may fix this issue.

 Indeed, I can confirm that changeset 16427 (which makes the development
 server multithreaded) fixes the bug for me. Going back to changeset 16426
 makes it fail again. Sorry for trying it out so late after PaulM's
 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.

Re: [Django] #16685: Improvement of comment for database host setting

2011-08-23 Thread Django

#16685: Improvement of comment for database host setting
-+-
   Reporter:  chromano   |  Owner:  nobody
   Type: | Status:  closed
  Uncategorized  |  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution:  duplicate  |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 This is a duplicate of #9920.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #9920: Empty string is not the same as typing "localhost" in DATABASE_HOST in settings.py

2011-08-23 Thread Django

#9920: Empty string is not the same as typing "localhost" in DATABASE_HOST in
settings.py
-+-
   Reporter:  crazy2k|  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Documentation
Version:  1.0|   Severity:  Normal
 Resolution: |   Keywords:  postgresql host
   Triage Stage:  Accepted   |  localhost empty
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by aaugustin):

 #16685 was a duplicate.

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

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

[Django] #16685: Improvement of comment for database host setting

2011-08-23 Thread Django

#16685: Improvement of comment for database host setting
---+--
 Reporter:  chromano   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Database layer (models, ORM)
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+--
 Currently, the database host setting contains the following comment:

 {{{
 'HOST': '', # Set to empty string for localhost. Not used with sqlite3.
 }}}


 However, it isn't true for postgres. An empty string is different from a
 "localhost" string in that the first one will make postgres uses a unix
 domain socket rather than a TCP connection.

 For default postgres configuration, this difference is the reason of an
 authentication problem. When using a domain socket, postgres uses "ident"
 as the authentication mechanism. By using ident authentication, users will
 only be able to authenticated in the DB if their OS username is the same
 as the DB username (which isn't necessarily true for a production
 environment, for example, where apache runs as "www-data" and the DB is
 owned by the "postgres" or the project owner's username).

 I think that a possible solution would be the improvement of this comment
 in order to let the user know about this problem or at least remove the
 part where it says that an empty is the same as "localhost".

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

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

2011-08-23 Thread Django

#12308: Adding tablespace support to postgres backends
-+-
   Reporter:  tclineks   |  Owner:  aaugustin
   Type:  New| Status:  new
  feature|  Component:  Database layer
  Milestone: |  (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 aaugustin):

 * status:  assigned => new
 * owner:  andrewsk => aaugustin


Comment:

 Since nothing happened in a year, I take the freedom of reassigning the
 ticket to myself.

 I'm interested in this because I'd like to be able to put the databases in
 a ramfs on the CI server.

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

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

2011-08-23 Thread Django

#12308: Adding tablespace support to postgres backends
-+-
   Reporter:  tclineks   |  Owner:  andrewsk
   Type:  New| Status:  assigned
  feature|  Component:  Database layer
  Milestone: |  (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 aaugustin):

 * ui_ux:   => 0


Comment:

 MySQL supports tablespaces since version 5.1 (catching up, eh?)

 http://dev.mysql.com/doc/refman/5.1/en/create-tablespace.html

 It may be possible to add support for tablespaces in MySQL at the same
 time with limited additional work.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16458: Equality operator on django.db.models.Model not commutative

2011-08-23 Thread Django

#16458: Equality operator on django.db.models.Model not commutative
-+-
   Reporter: |  Owner:  teraom
  freek.wiekmeijer@… | Status:  assigned
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by akaariai):

 * needs_docs:  0 => 1


Comment:

 The "bag-equality" is implemented in a new patch. The approach is a set
 intersection done in `__eq__`. The `__eq__` will check if the instances
 compared share any multi-table inherited parent (in this case a model is
 its own parent), and if so, then check the equality of the PK.

 The performance is 50% slower in for-loop testing obj==obj repeatedly. I
 don't believe the speed is much worse for large inheritance chains, at
 least not for any practical ones.

 Proxy and deferred models should be handled OK in the patch.

 There is one test that needs fixing. Admin's `NestedCollector` (collects
 objects to delete) assumes an object is never equal to its parent. This is
 fixed, but in a different patch. I am afraid the new equality behavior
 will cause similar errors for users when they are upgrading Django.

 After the fix, all tests should pass.

 The patch needs documentation and some polishing, especially the attribute
 name ._meta.concrete_models is not good enough...

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16684: BaseForm needs to escape the 'class' attribute value

2011-08-23 Thread Django

#16684: BaseForm needs to escape the 'class' attribute value
---+
 Reporter:  dtrebbien  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Forms
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+
 In the `_html_output` method of class `django.forms.forms.BaseForm`, this
 line:

 {{{#!python
 html_class_attr = ' class="%s"' % css_classes
 }}}

 needs to be changed to:

 {{{#!python
 html_class_attr = ' class="%s"' % conditional_escape(css_classes)
 }}}

 This is because [http://www.w3.org/TR/CSS21/syndata.html#characters CSS
 identifiers can contain escape characters]:

 > For instance, the identifier "B?" may be written as "B\\?" or "B\26
 W\3F".


 \\Note that the attached patch is against 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] #16681: modeltests.invalid_models tests are a weird special case

2011-08-23 Thread Django

#16681: modeltests.invalid_models tests are a weird special case
-+-
 Reporter:  anthonyb |  Owner:  nobody
 Type:   | Status:  closed
  Cleanup/optimization   |  Component:  Testing framework
Milestone:   |   Severity:  Normal
  Version:  1.3  |   Keywords:  invalid models
   Resolution:  fixed|  invalid_models
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+-

Comment (by russellm):

 In [16674]:
 {{{
 #!CommitTicketReference repository="" revision="16674"
 [1.3.X] Fixed #16681 -- Refactored the invalid_models unit test so that it
 can be invoked manually. Thanks to Anthony Briggs for the report and
 patch.

 Backport of r16661 from trunk.
 }}}

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

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

[Changeset] r16677 - django/branches/releases/1.3.X/tests/modeltests/invalid_models

2011-08-23 Thread noreply

Author: russellm
Date: 2011-08-23 08:57:19 -0700 (Tue, 23 Aug 2011)
New Revision: 16677

Modified:
   django/branches/releases/1.3.X/tests/modeltests/invalid_models/tests.py
Log:
[1.3.X] Corrected the setup and teardown of the refactored invalid_models test 
so that it guarantees that stdout is restored, and purges all the temporary 
models from the app cache after running the test.

Backport of r16670 from trunk.

Modified: 
django/branches/releases/1.3.X/tests/modeltests/invalid_models/tests.py
===
--- django/branches/releases/1.3.X/tests/modeltests/invalid_models/tests.py 
2011-08-23 15:57:01 UTC (rev 16676)
+++ django/branches/releases/1.3.X/tests/modeltests/invalid_models/tests.py 
2011-08-23 15:57:19 UTC (rev 16677)
@@ -1,3 +1,8 @@
+import copy
+
+from django.core.management.validation import get_validation_errors
+from django.db.models.loading import cache, load_app
+from cStringIO import StringIO
 import sys
 
 from django.utils import unittest
@@ -6,26 +11,36 @@
 class InvalidModelTestCase(unittest.TestCase):
 """Import an appliation with invalid models and test the exceptions."""
 
+def setUp(self):
+# Make sure sys.stdout is not a tty so that we get errors without
+# coloring attached (makes matching the results easier). We restore
+# sys.stderr afterwards.
+self.old_stdout = sys.stdout
+self.stdout = StringIO()
+sys.stdout = self.stdout
+
+# This test adds dummy applications to the app cache. These
+# need to be removed in order to prevent bad interactions
+# with the flush operation in other tests.
+self.old_app_models = copy.deepcopy(cache.app_models)
+self.old_app_store = copy.deepcopy(cache.app_store)
+
+def tearDown(self):
+cache.app_models = self.old_app_models
+cache.app_store = self.old_app_store
+cache._get_models_cache = {}
+sys.stdout = self.old_stdout
+
 def test_invalid_models(self):
-from django.core.management.validation import get_validation_errors
-from django.db.models.loading import load_app
-from cStringIO import StringIO
 
 try:
 module = load_app("modeltests.invalid_models.invalid_models")
 except Exception, e:
 self.fail('Unable to load invalid model module')
 
-# Make sure sys.stdout is not a tty so that we get errors without
-# coloring attached (makes matching the results easier). We restore
-# sys.stderr afterwards.
-orig_stdout = sys.stdout
-s = StringIO()
-sys.stdout = s
-count = get_validation_errors(s, module)
-sys.stdout = orig_stdout
-s.seek(0)
-error_log = s.read()
+count = get_validation_errors(self.stdout, module)
+self.stdout.seek(0)
+error_log = self.stdout.read()
 actual = error_log.split('\n')
 expected = module.model_errors.split('\n')
 
@@ -33,5 +48,3 @@
 missing = [err for err in expected if err not in actual]
 self.assertFalse(unexpected, "Unexpected Errors: " + 
'\n'.join(unexpected))
 self.assertFalse(missing, "Missing Errors: " + '\n'.join(missing))
-
-

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r16676 - in django/branches/releases/1.3.X: django/http tests/regressiontests/requests

2011-08-23 Thread noreply

Author: russellm
Date: 2011-08-23 08:57:01 -0700 (Tue, 23 Aug 2011)
New Revision: 16676

Modified:
   django/branches/releases/1.3.X/django/http/multipartparser.py
   django/branches/releases/1.3.X/tests/regressiontests/requests/tests.py
Log:
[1.3.X] Fixed #16201 -- Ensure that requests with Content-Length=0 don't break 
the multipart parser. Thanks to albsen for the report and patch

Backport of r16353 from trunk.

Modified: django/branches/releases/1.3.X/django/http/multipartparser.py
===
--- django/branches/releases/1.3.X/django/http/multipartparser.py   
2011-08-23 15:56:40 UTC (rev 16675)
+++ django/branches/releases/1.3.X/django/http/multipartparser.py   
2011-08-23 15:57:01 UTC (rev 16676)
@@ -75,7 +75,7 @@
 # For now set it to 0; we'll try again later on down.
 content_length = 0
 
-if content_length <= 0:
+if content_length < 0:
 # This means we shouldn't continue...raise an error.
 raise MultiPartParserError("Invalid content length: %r" % 
content_length)
 
@@ -105,6 +105,11 @@
 encoding = self._encoding
 handlers = self._upload_handlers
 
+# HTTP spec says that Content-Length >= 0 is valid
+# handling content-length == 0 before continuing
+if self._content_length == 0:
+return QueryDict(MultiValueDict(), encoding=self._encoding), 
MultiValueDict()
+
 limited_input_data = LimitBytes(self._input_data, self._content_length)
 
 # See if the handler will want to take care of the parsing.

Modified: django/branches/releases/1.3.X/tests/regressiontests/requests/tests.py
===
--- django/branches/releases/1.3.X/tests/regressiontests/requests/tests.py  
2011-08-23 15:56:40 UTC (rev 16675)
+++ django/branches/releases/1.3.X/tests/regressiontests/requests/tests.py  
2011-08-23 15:57:01 UTC (rev 16676)
@@ -200,6 +200,27 @@
 self.assertEqual(request.POST, {u'name': [u'value']})
 self.assertRaises(Exception, lambda: request.raw_post_data)
 
+def test_POST_multipart_with_content_length_zero(self):
+"""
+Multipart POST requests with Content-Length >= 0 are valid and need to 
be handled.
+"""
+# According to:
+# http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13
+# Every request.POST with Content-Length >= 0 is a valid request,
+# this test ensures that we handle Content-Length == 0.
+payload = "\r\n".join([
+'--boundary',
+'Content-Disposition: form-data; name="name"',
+'',
+'value',
+'--boundary--'
+''])
+request = WSGIRequest({'REQUEST_METHOD': 'POST',
+   'CONTENT_TYPE': 'multipart/form-data; 
boundary=boundary',
+   'CONTENT_LENGTH': 0,
+   'wsgi.input': StringIO(payload)})
+self.assertEqual(request.POST, {})
+
 def test_read_by_lines(self):
 request = WSGIRequest({'REQUEST_METHOD': 'POST', 'wsgi.input': 
StringIO('name=value')})
 self.assertEqual(list(request), ['name=value'])

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16201: When Content-Length is 0, MultiPartParser violates RFC2616

2011-08-23 Thread Django

#16201: When Content-Length is 0, MultiPartParser violates RFC2616
-+-
   Reporter:  albsen |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  HTTP handling
Version:  1.3-rc1|   Severity:  Normal
 Resolution:  fixed  |   Keywords:  http multipart
   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 russellm):

 In [16676]:
 {{{
 #!CommitTicketReference repository="" revision="16676"
 [1.3.X] Fixed #16201 -- Ensure that requests with Content-Length=0 don't
 break the multipart parser. Thanks to albsen for the report and patch

 Backport of r16353 from trunk.
 }}}

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

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

Re: [Django] #16299: Django model-module doesn't support unicode_literals

2011-08-23 Thread Django

#16299: Django model-module doesn't support unicode_literals
-+-
   Reporter: |  Owner:  nobody
  martijn.bastiaan@… | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:  unicode,
   Triage Stage:  Accepted   |  ForeignKey, AttributeError
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  1
-+-

Comment (by russellm):

 In [16675]:
 {{{
 #!CommitTicketReference repository="" revision="16675"
 [1.3.X] Fixed #16299 -- Ensure that unicode strings can be used to
 identify classes in ForeignKey and ManyToManyFields. Unicode strings
 aren't actually legal as class names, but this is an issue if you use from
 __future__ import unicode_literals in your models.py file. Thanks to
 Martijn Bastiaan for the report, and Anthony Briggs for the final patch.

 Backport of r16663 from trunk.
 }}}

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

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

[Changeset] r16675 - in django/branches/releases/1.3.X: django/db/models tests/modeltests/invalid_models/invalid_models

2011-08-23 Thread noreply

Author: russellm
Date: 2011-08-23 08:56:40 -0700 (Tue, 23 Aug 2011)
New Revision: 16675

Modified:
   django/branches/releases/1.3.X/django/db/models/options.py
   
django/branches/releases/1.3.X/tests/modeltests/invalid_models/invalid_models/models.py
Log:
[1.3.X] Fixed #16299 -- Ensure that unicode strings can be used to identify 
classes in ForeignKey and ManyToManyFields. Unicode strings aren't actually 
legal as class names, but this is an issue if you use from __future__ import 
unicode_literals in your models.py file. Thanks to Martijn Bastiaan for the 
report, and Anthony Briggs for the final patch.

Backport of r16663 from trunk.

Modified: django/branches/releases/1.3.X/django/db/models/options.py
===
--- django/branches/releases/1.3.X/django/db/models/options.py  2011-08-23 
15:56:18 UTC (rev 16674)
+++ django/branches/releases/1.3.X/django/db/models/options.py  2011-08-23 
15:56:40 UTC (rev 16675)
@@ -390,7 +390,7 @@
 cache[obj] = model
 for klass in get_models(include_auto_created=True):
 for f in klass._meta.local_fields:
-if f.rel and not isinstance(f.rel.to, str) and self == 
f.rel.to._meta:
+if f.rel and not isinstance(f.rel.to, basestring) and self == 
f.rel.to._meta:
 cache[RelatedObject(f.rel.to, klass, f)] = None
 self._related_objects_cache = cache
 
@@ -427,7 +427,7 @@
 cache[obj] = model
 for klass in get_models():
 for f in klass._meta.local_many_to_many:
-if f.rel and not isinstance(f.rel.to, str) and self == 
f.rel.to._meta:
+if f.rel and not isinstance(f.rel.to, basestring) and self == 
f.rel.to._meta:
 cache[RelatedObject(f.rel.to, klass, f)] = None
 if app_cache_ready():
 self._related_many_to_many_cache = cache

Modified: 
django/branches/releases/1.3.X/tests/modeltests/invalid_models/invalid_models/models.py
===
--- 
django/branches/releases/1.3.X/tests/modeltests/invalid_models/invalid_models/models.py
 2011-08-23 15:56:18 UTC (rev 16674)
+++ 
django/branches/releases/1.3.X/tests/modeltests/invalid_models/invalid_models/models.py
 2011-08-23 15:56:40 UTC (rev 16675)
@@ -1,3 +1,4 @@
+#encoding=utf-8
 """
 26. Invalid models
 
@@ -218,6 +219,16 @@
 class InvalidSetDefault(models.Model):
 fk = models.ForeignKey('self', on_delete=models.SET_DEFAULT)
 
+class UnicodeForeignKeys(models.Model):
+"""Foreign keys which can translate to ascii should be OK, but fail if 
they're not."""
+good = models.ForeignKey(u'FKTarget')
+also_good = models.ManyToManyField(u'FKTarget', related_name='unicode2')
+
+# In Python 3 this should become legal, but currently causes unicode errors
+# when adding the errors in core/management/validation.py
+#bad = models.ForeignKey(u'★')
+
+
 model_errors = """invalid_models.fielderrors: "charfield": CharFields require 
a "max_length" attribute that is a positive integer.
 invalid_models.fielderrors: "charfield2": CharFields require a "max_length" 
attribute that is a positive integer.
 invalid_models.fielderrors: "charfield3": CharFields require a "max_length" 
attribute that is a positive integer.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r16673 - in django/branches/releases/1.3.X: django/utils docs/topics tests/regressiontests/cache

2011-08-23 Thread noreply

Author: russellm
Date: 2011-08-23 08:55:48 -0700 (Tue, 23 Aug 2011)
New Revision: 16673

Modified:
   django/branches/releases/1.3.X/django/utils/cache.py
   django/branches/releases/1.3.X/docs/topics/cache.txt
   django/branches/releases/1.3.X/tests/regressiontests/cache/tests.py
Log:
[1.3.X] Fixed #15499 -- Ensure that cache control headers don't try to set 
public and private as a result of multiple calls to patch_cache_control with 
different arguments. Thanks to AndiDog for the report and patch.

Backport of r16657 from trunk.

Modified: django/branches/releases/1.3.X/django/utils/cache.py
===
--- django/branches/releases/1.3.X/django/utils/cache.py2011-08-23 
15:55:22 UTC (rev 16672)
+++ django/branches/releases/1.3.X/django/utils/cache.py2011-08-23 
15:55:48 UTC (rev 16673)
@@ -67,6 +67,12 @@
 if 'max-age' in cc and 'max_age' in kwargs:
 kwargs['max_age'] = min(cc['max-age'], kwargs['max_age'])
 
+# Allow overriding private caching and vice versa
+if 'private' in cc and 'public' in kwargs:
+del cc['private']
+elif 'public' in cc and 'private' in kwargs:
+del cc['public']
+
 for (k, v) in kwargs.items():
 cc[k.replace('_', '-')] = v
 cc = ', '.join([dictvalue(el) for el in cc.items()])

Modified: django/branches/releases/1.3.X/docs/topics/cache.txt
===
--- django/branches/releases/1.3.X/docs/topics/cache.txt2011-08-23 
15:55:22 UTC (rev 16672)
+++ django/branches/releases/1.3.X/docs/topics/cache.txt2011-08-23 
15:55:48 UTC (rev 16673)
@@ -1062,6 +1062,28 @@
 This decorator takes care of sending out the appropriate HTTP header behind the
 scenes.
 
+Note that the cache control settings "private" and "public" are mutually
+exclusive. The decorator ensures that the "public" directive is removed if
+"private" should be set (and vice versa). An example use of the two directives
+would be a blog site that offers both private and public entries. Public
+entries may be cached on any shared cache. The following code uses
+``patch_cache_control``, the manual way to modify the cache control header
+(it is internally called by the ``cache_control`` decorator)::
+
+from django.views.decorators.cache import patch_cache_control
+from django.views.decorators.vary import vary_on_cookie
+
+@vary_on_cookie
+def list_blog_entries_view(request):
+if request.user.is_anonymous():
+response = render_only_public_entries()
+patch_cache_control(response, public=True)
+else:
+response = render_private_and_public_entries(request.user)
+patch_cache_control(response, private=True)
+
+return response
+
 There are a few other ways to control cache parameters. For example, HTTP
 allows applications to do the following:
 

Modified: django/branches/releases/1.3.X/tests/regressiontests/cache/tests.py
===
--- django/branches/releases/1.3.X/tests/regressiontests/cache/tests.py 
2011-08-23 15:55:22 UTC (rev 16672)
+++ django/branches/releases/1.3.X/tests/regressiontests/cache/tests.py 
2011-08-23 15:55:48 UTC (rev 16673)
@@ -4,6 +4,7 @@
 # Uses whatever cache backend is set in the test settings file.
 
 import os
+import re
 import tempfile
 import time
 import warnings
@@ -18,7 +19,7 @@
 from django.test.utils import get_warnings_state, restore_warnings_state
 from django.utils import translation
 from django.utils import unittest
-from django.utils.cache import patch_vary_headers, get_cache_key, 
learn_cache_key
+from django.utils.cache import patch_vary_headers, get_cache_key, 
learn_cache_key, patch_cache_control
 from django.utils.hashcompat import md5_constructor
 from django.views.decorators.cache import cache_page
 
@@ -970,6 +971,31 @@
 learn_cache_key(request, response)
 self.assertEqual(get_cache_key(request), 
'views.decorators.cache.cache_page.settingsprefix.HEAD.a8c87a3d8c44853d7f79474f7ffe4ad5.d41d8cd98f00b204e9800998ecf8427e')
 
+def test_patch_cache_control(self):
+tests = (
+# Initial Cache-Control, kwargs to patch_cache_control, expected 
Cache-Control parts
+(None, {'private' : True}, set(['private'])),
+
+# Test whether private/public attributes are mutually exclusive
+('private', {'private' : True}, set(['private'])),
+('private', {'public' : True}, set(['public'])),
+('public', {'public' : True}, set(['public'])),
+('public', {'private' : True}, set(['private'])),
+('must-revalidate,max-age=60,private', {'public' : True}, 
set(['must-revalidate', 'max-age=60', 'public'])),
+('must-revalidate,max-age=60,public', {'private' : True}, 
set(['must-revalidate', 'max-age=60', 'private'])),
+

Re: [Django] #15499: patch_cache_control should replace public/private setting if already set

2011-08-23 Thread Django

#15499: patch_cache_control should replace public/private setting if already set
-+-
   Reporter:  AndiDog|  Owner:  AndiDog
   Type:  Bug| Status:  closed
  Milestone: |  Component:  HTTP handling
Version:  SVN|   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 russellm):

 In [16673]:
 {{{
 #!CommitTicketReference repository="" revision="16673"
 [1.3.X] Fixed #15499 -- Ensure that cache control headers don't try to set
 public and private as a result of multiple calls to patch_cache_control
 with different arguments. Thanks to AndiDog for the report and patch.

 Backport of r16657 from trunk.
 }}}

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

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

Re: [Django] #10571: FakePayload Truncates Unicode Content

2011-08-23 Thread Django

#10571: FakePayload Truncates Unicode Content
-+-
   Reporter:  rwagner@…  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone:  1.1|  Component:  Testing framework
Version:  SVN|   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 russellm):

 In [16672]:
 {{{
 #!CommitTicketReference repository="" revision="16672"
 [1.3.X] Fixed #10571 -- Factored out the payload encoding code to make
 sure it is used for PUT requests. Thanks to kennu for the report, pterk
 for the patch, and wildfire for the review comments.

 Backport of r16651 from trunk.
 }}}

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

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

[Changeset] r16672 - in django/branches/releases/1.3.X: django/test tests/regressiontests/test_client_regress

2011-08-23 Thread noreply

Author: russellm
Date: 2011-08-23 08:55:22 -0700 (Tue, 23 Aug 2011)
New Revision: 16672

Modified:
   django/branches/releases/1.3.X/django/test/client.py
   
django/branches/releases/1.3.X/tests/regressiontests/test_client_regress/models.py
Log:
[1.3.X] Fixed #10571 -- Factored out the payload encoding code to make sure it 
is used for PUT requests. Thanks to kennu for the report, pterk for the patch, 
and wildfire for the review comments.

Backport of r16651 from trunk.

Modified: django/branches/releases/1.3.X/django/test/client.py
===
--- django/branches/releases/1.3.X/django/test/client.py2011-08-23 
15:54:45 UTC (rev 16671)
+++ django/branches/releases/1.3.X/django/test/client.py2011-08-23 
15:55:22 UTC (rev 16672)
@@ -207,6 +207,18 @@
 "Construct a generic request object."
 return WSGIRequest(self._base_environ(**request))
 
+def _encode_data(self, data, content_type, ):
+if content_type is MULTIPART_CONTENT:
+return encode_multipart(BOUNDARY, data)
+else:
+# Encode the content so that the byte representation is correct.
+match = CONTENT_TYPE_RE.match(content_type)
+if match:
+charset = match.group(1)
+else:
+charset = settings.DEFAULT_CHARSET
+return smart_str(data, encoding=charset)
+
 def _get_path(self, parsed):
 # If there are parameters, add them
 if parsed[3]:
@@ -232,16 +244,7 @@
  **extra):
 "Construct a POST request."
 
-if content_type is MULTIPART_CONTENT:
-post_data = encode_multipart(BOUNDARY, data)
-else:
-# Encode the content so that the byte representation is correct.
-match = CONTENT_TYPE_RE.match(content_type)
-if match:
-charset = match.group(1)
-else:
-charset = settings.DEFAULT_CHARSET
-post_data = smart_str(data, encoding=charset)
+post_data = self._encode_data(data, content_type)
 
 parsed = urlparse(path)
 r = {
@@ -286,25 +289,16 @@
 **extra):
 "Construct a PUT request."
 
-if content_type is MULTIPART_CONTENT:
-post_data = encode_multipart(BOUNDARY, data)
-else:
-post_data = data
+put_data = self._encode_data(data, content_type)
 
-# Make `data` into a querystring only if it's not already a string. If
-# it is a string, we'll assume that the caller has already encoded it.
-query_string = None
-if not isinstance(data, basestring):
-query_string = urlencode(data, doseq=True)
-
 parsed = urlparse(path)
 r = {
-'CONTENT_LENGTH': len(post_data),
+'CONTENT_LENGTH': len(put_data),
 'CONTENT_TYPE':   content_type,
 'PATH_INFO':  self._get_path(parsed),
-'QUERY_STRING':   query_string or parsed[4],
+'QUERY_STRING':   parsed[4],
 'REQUEST_METHOD': 'PUT',
-'wsgi.input': FakePayload(post_data),
+'wsgi.input': FakePayload(put_data),
 }
 r.update(extra)
 return self.request(**r)

Modified: 
django/branches/releases/1.3.X/tests/regressiontests/test_client_regress/models.py
===
--- 
django/branches/releases/1.3.X/tests/regressiontests/test_client_regress/models.py
  2011-08-23 15:54:45 UTC (rev 16671)
+++ 
django/branches/releases/1.3.X/tests/regressiontests/test_client_regress/models.py
  2011-08-23 15:55:22 UTC (rev 16672)
@@ -756,7 +756,9 @@
 
 class QueryStringTests(TestCase):
 def test_get_like_requests(self):
-for method_name in ('get','head','options','put','delete'):
+# See: https://code.djangoproject.com/ticket/10571.
+# Removed 'put' and 'delete' here as they are 'GET-like requests'
+for method_name in ('get','head','options'):
 # A GET-like request can pass a query string as data
 method = getattr(self.client, method_name)
 response = method("/test_client_regress/request_data/", 
data={'foo':'whiz'})
@@ -813,6 +815,9 @@
 response = 
self.client.post("/test_client_regress/parse_unicode_json/", json,
 content_type="application/json")
 self.assertEqual(response.content, json)
+response = self.client.put("/test_client_regress/parse_unicode_json/", 
json,
+content_type="application/json")
+self.assertEqual(response.content, json)
 
 def test_unicode_payload_utf8(self):
 "A non-ASCII unicode data encoded as UTF-8 can be POSTed"
@@ -821,6 +826,9 @@
 response = 
self.client.post("/test_client_regress/parse_unicode_json/", json,

[Changeset] r16671 - in django/branches/releases/1.3.X: django/db/models/sql tests/regressiontests/queries

2011-08-23 Thread noreply

Author: russellm
Date: 2011-08-23 08:54:45 -0700 (Tue, 23 Aug 2011)
New Revision: 16671

Modified:
   django/branches/releases/1.3.X/django/db/models/sql/query.py
   django/branches/releases/1.3.X/tests/regressiontests/queries/tests.py
Log:
[1.3.X] Fixed #14876 -- Ensure that join promotion works correctly when there 
are nullable related fields. Thanks to simonpercivall for the report, oinopion 
and Aleksandra Sendecka for the original patch, and to Malcolm for helping me 
wrestle the edge cases to the ground.

Backport of r16648 from trunk.

Modified: django/branches/releases/1.3.X/django/db/models/sql/query.py
===
--- django/branches/releases/1.3.X/django/db/models/sql/query.py
2011-08-23 15:36:40 UTC (rev 16670)
+++ django/branches/releases/1.3.X/django/db/models/sql/query.py
2011-08-23 15:54:45 UTC (rev 16671)
@@ -440,8 +440,6 @@
 "Cannot combine a unique query with a non-unique query."
 
 self.remove_inherited_models()
-l_tables = set([a for a in self.tables if self.alias_refcount[a]])
-r_tables = set([a for a in rhs.tables if rhs.alias_refcount[a]])
 # Work out how to relabel the rhs aliases, if necessary.
 change_map = {}
 used = set()
@@ -462,16 +460,27 @@
 # all joins exclusive to either the lhs or the rhs must be converted
 # to an outer join.
 if not conjunction:
+l_tables = set(self.tables)
+r_tables = set(rhs.tables)
 # Update r_tables aliases.
 for alias in change_map:
 if alias in r_tables:
-r_tables.remove(alias)
-r_tables.add(change_map[alias])
+# r_tables may contain entries that have a refcount of 0
+# if the query has references to a table that can be
+# trimmed because only the foreign key is used.
+# We only need to fix the aliases for the tables that
+# actually have aliases.
+if rhs.alias_refcount[alias]:
+r_tables.remove(alias)
+r_tables.add(change_map[alias])
 # Find aliases that are exclusive to rhs or lhs.
 # These are promoted to outer joins.
-outer_aliases = (l_tables | r_tables) - (l_tables & r_tables)
-for alias in outer_aliases:
-self.promote_alias(alias, True)
+outer_tables = (l_tables | r_tables) - (l_tables & r_tables)
+for alias in outer_tables:
+# Again, some of the tables won't have aliases due to
+# the trimming of unnecessary tables.
+if self.alias_refcount.get(alias) or 
rhs.alias_refcount.get(alias):
+self.promote_alias(alias, True)
 
 # Now relabel a copy of the rhs where-clause and add it to the current
 # one.
@@ -656,7 +665,7 @@
 False, the join is only promoted if it is nullable, otherwise it is
 always promoted.
 
-Returns True if the join was promoted.
+Returns True if the join was promoted by this call.
 """
 if ((unconditional or self.alias_map[alias][NULLABLE]) and
 self.alias_map[alias][JOIN_TYPE] != self.LOUTER):
@@ -1063,17 +1072,20 @@
 can_reuse)
 return
 
+table_promote = False
+join_promote = False
+
 if (lookup_type == 'isnull' and value is True and not negate and
 len(join_list) > 1):
 # If the comparison is against NULL, we may need to use some left
 # outer joins when creating the join chain. This is only done when
 # needed, as it's less efficient at the database level.
 self.promote_alias_chain(join_list)
+join_promote = True
 
 # Process the join list to see if we can remove any inner joins from
 # the far end (fewer tables in a query is better).
 col, alias, join_list = self.trim_joins(target, join_list, last, trim)
-
 if connector == OR:
 # Some joins may need to be promoted when adding a new filter to a
 # disjunction. We walk the list of new joins and where it diverges
@@ -1083,20 +1095,30 @@
 join_it = iter(join_list)
 table_it = iter(self.tables)
 join_it.next(), table_it.next()
-table_promote = False
-join_promote = False
+unconditional = False
 for join in join_it:
 table = table_it.next()
+# Once we hit an outer join, all subsequent joins must
+# also be promoted, regardless of whether they have been
+# promoted as a result of this pass through the tables.
+unconditional = (unconditional or
+

Re: [Django] #14876: Q | Q with nullable related fields generates INNER JOIN where it should be LEFT JOIN

2011-08-23 Thread Django

#14876: Q | Q with nullable related fields generates INNER JOIN where it should 
be
LEFT JOIN
-+-
   Reporter: |  Owner:  oinopion
  simonpercivall | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.2|   Severity:  Normal
 Resolution:  fixed  |   Keywords:  Q,inner
   Triage Stage:  Ready for  |  join,nullable,dceu2011
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by russellm):

 In [16671]:
 {{{
 #!CommitTicketReference repository="" revision="16671"
 [1.3.X] Fixed #14876 -- Ensure that join promotion works correctly when
 there are nullable related fields. Thanks to simonpercivall for the
 report, oinopion and Aleksandra Sendecka for the original patch, and to
 Malcolm for helping me wrestle the edge cases to the ground.

 Backport of r16648 from trunk.
 }}}

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

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

[Changeset] r16670 - django/trunk/tests/modeltests/invalid_models

2011-08-23 Thread noreply

Author: russellm
Date: 2011-08-23 08:36:40 -0700 (Tue, 23 Aug 2011)
New Revision: 16670

Modified:
   django/trunk/tests/modeltests/invalid_models/tests.py
Log:
Corrected the setup and teardown of the refactored invalid_models test so that 
it guarantees that stdout is restored, and purges all the temporary models from 
the app cache after running the test.

Modified: django/trunk/tests/modeltests/invalid_models/tests.py
===
--- django/trunk/tests/modeltests/invalid_models/tests.py   2011-08-23 
06:31:03 UTC (rev 16669)
+++ django/trunk/tests/modeltests/invalid_models/tests.py   2011-08-23 
15:36:40 UTC (rev 16670)
@@ -1,3 +1,8 @@
+import copy
+
+from django.core.management.validation import get_validation_errors
+from django.db.models.loading import cache, load_app
+from cStringIO import StringIO
 import sys
 
 from django.utils import unittest
@@ -6,26 +11,36 @@
 class InvalidModelTestCase(unittest.TestCase):
 """Import an appliation with invalid models and test the exceptions."""
 
+def setUp(self):
+# Make sure sys.stdout is not a tty so that we get errors without
+# coloring attached (makes matching the results easier). We restore
+# sys.stderr afterwards.
+self.old_stdout = sys.stdout
+self.stdout = StringIO()
+sys.stdout = self.stdout
+
+# This test adds dummy applications to the app cache. These
+# need to be removed in order to prevent bad interactions
+# with the flush operation in other tests.
+self.old_app_models = copy.deepcopy(cache.app_models)
+self.old_app_store = copy.deepcopy(cache.app_store)
+
+def tearDown(self):
+cache.app_models = self.old_app_models
+cache.app_store = self.old_app_store
+cache._get_models_cache = {}
+sys.stdout = self.old_stdout
+
 def test_invalid_models(self):
-from django.core.management.validation import get_validation_errors
-from django.db.models.loading import load_app
-from cStringIO import StringIO
 
 try:
 module = load_app("modeltests.invalid_models.invalid_models")
 except Exception, e:
 self.fail('Unable to load invalid model module')
 
-# Make sure sys.stdout is not a tty so that we get errors without
-# coloring attached (makes matching the results easier). We restore
-# sys.stderr afterwards.
-orig_stdout = sys.stdout
-s = StringIO()
-sys.stdout = s
-count = get_validation_errors(s, module)
-sys.stdout = orig_stdout
-s.seek(0)
-error_log = s.read()
+count = get_validation_errors(self.stdout, module)
+self.stdout.seek(0)
+error_log = self.stdout.read()
 actual = error_log.split('\n')
 expected = module.model_errors.split('\n')
 
@@ -33,5 +48,3 @@
 missing = [err for err in expected if err not in actual]
 self.assertFalse(unexpected, "Unexpected Errors: " + 
'\n'.join(unexpected))
 self.assertFalse(missing, "Missing Errors: " + '\n'.join(missing))
-
-

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16683: Make ipv6 tests in regressiontests.admin_scripts.tests.ManageRunserver skippable if ipv6 support isn't present

2011-08-23 Thread Django

#16683: Make ipv6 tests in regressiontests.admin_scripts.tests.ManageRunserver
skippable if ipv6 support isn't present
+---
   Reporter:  bugs@…|  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Testing framework
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by anonymous):

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


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

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

Re: [Django] #15729: Cache middleware issues after restart when using mod_wsgi with PyLibMC

2011-08-23 Thread Django

#15729: Cache middleware issues after restart when using mod_wsgi with PyLibMC
-+-
   Reporter:  jsdalton   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Cache system)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by obeattie):

 * cc: oliver@… (added)
 * ui_ux:   => 0


Comment:

 Has it actually been brought to the attention of the pylibmc/libmemcached
 folks?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16683: Make ipv6 tests in regressiontests.admin_scripts.tests.ManageRunserver skippable if ipv6 support isn't present

2011-08-23 Thread Django

#16683: Make ipv6 tests in regressiontests.admin_scripts.tests.ManageRunserver
skippable if ipv6 support isn't present
+---
 Reporter:  bugs@…  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  Testing framework
  Version:  1.3 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  0   |
+---
 Running the test suite with a python without ipv6 support will result in
 this:
 {{{
 ==
 ERROR: test_runserver_addrport
 (regressiontests.admin_scripts.tests.ManageRunserver)
 --
 Traceback (most recent call last):
   File "/var/tmp/portage/dev-
 
python/django-1.3/work/Django-1.3/tests/regressiontests/admin_scripts/tests.py",
 line 1056, in test_runserver_addrport
 self.cmd.handle(addrport="", use_ipv6=True)
   File "/var/tmp/portage/dev-
 
python/django-1.3/work/Django-1.3/django/core/management/commands/runserver.py",
 line 42, in handle
 raise CommandError('Your Python does not support IPv6.')
 CommandError: Your Python does not support IPv6.
 }}}

 The test runner should skip these tests if ipv6 isn't available.

 FWIW, Gentoo bug with moar output here:
 https://bugs.gentoo.org/show_bug.cgi?id=371057

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16458: Equality operator on django.db.models.Model not commutative

2011-08-23 Thread Django

#16458: Equality operator on django.db.models.Model not commutative
-+-
   Reporter: |  Owner:  teraom
  freek.wiekmeijer@… | Status:  assigned
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by akaariai):

 Hmm, shouldn't models then be equal if they have a common parent class.
 Consider situation:

 {{{
 class Restaurant(models.Model):
 pass

 class ItalianRestaurant(Restaurant):
pass

 class EnglishRestaurant(Restaurant):
pass

 r = Restaurant(pk=1)
 i = ItalianRestaurant(restaurant=r)
 e = EnglishRestaurant(restaurant=r)

 }}}

 Then, shouldn't i==e be True, even though neither is a subclass of the
 other.

 I admit this is a bit of a stretch, but that would be the most consistent
 behaviour IMHO. Making this fast and correct for large inheritance trees
 seems to be a bit of a challenge. Deciding that this is not needed
 wouldn't be a bad decision.

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

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

2011-08-23 Thread Django

#6947: Auto increment field in sqlite
-+-
   Reporter: |  Owner:  nobody
  ctrochalakis   | Status:  closed
   Type: |  Component:  Database layer
  Uncategorized  |  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  sqlite
 Resolution:  invalid|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by django.bigfudge@…):

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


Comment:

 I'm not reopening this ticket myself, but I would like to petition for it
 to be reopened because of a specific problem with django_reversion, and
 likely other code intended to version django objects.

 Quite reasonably, reversion versions are not deleted when an original
 object is deleted. However, versions do use the deleted objects' id to
 link back to that object. If using sqlite, when an object is deleted then
 it's pk is freed up for reuse. When this happens, reversion_versions link
 back to the wrong object, and in the admin it looks like there are more
 versions than there actually are ( you get the full history for any object
 which has had the pk in question).

 Were Sebastian right that AUTOINCREMENT would only add new rows with
 largest pk+1 then this would still be a problem: the object with the
 largest PK could be deleted, and a new one would reuse this pk, and this
 would still confuse reversion. However, quoting from the SQLITE docs:

 "The behavior implemented by the AUTOINCREMENT keyword is subtly different
 from the default behavior. With AUTOINCREMENT, rows with automatically
 selected ROWIDs are guaranteed to have ROWIDs that have never been used
 before by the same table in the same database."
 http://www.sqlite.org/autoinc.html

 So, if the AUTOINCREMENT keyword were added by django when creating tables
 then this would prevent reversion getting confused. I'll cross post this
 to the reversion people, but it seems to me that fixing django would be a
 lot easier than trying to make the reversion app compatible with sqlite.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15099: ModelFormset.queryset requirement is too strict

2011-08-23 Thread Django

#15099: ModelFormset.queryset requirement is too strict
+
   Reporter:  Ciantic   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Forms
Version:  1.2   |   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 dtrebbien):

 * cc: dtrebbien (added)
 * ui_ux:   => 0
 * easy:   => 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] #3055: GenericRelation should squawk if pointed to a model that doesn't have a GenericForeignKey on it

2011-08-23 Thread Django

#3055: GenericRelation should squawk if pointed to a model that doesn't have a
GenericForeignKey on it
-+-
   Reporter:  panta@…|  Owner:  marcosmoyano
   Type:  defect | Status:  reopened
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  major
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by mtredinnick):

 * stage:  Ready for checkin => Accepted


Comment:

 Moving out of "ready for checkin" status, since the patch requires
 rethinking.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #13640: add_filter in django/db/models/ sql/query.py causes exception when model have 'evaluate' attribute

2011-08-23 Thread Django

#13640: add_filter in django/db/models/ sql/query.py causes exception when model
have 'evaluate' attribute
-+-
   Reporter: |  Owner:  tobias
  LukaszKorzybski| Status:  assigned
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  1  |  Easy pickings:  1
  UI/UX:  0  |
-+-
Changes (by mtredinnick):

 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * stage:  Ready for checkin => Accepted


Comment:

 I don't understand the claim that this doesn't need a test. Either it
 currently works properly, or the change is needed. If the change is
 needed, it requires a test to ensure we don't break it again in the
 future.

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

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

2011-08-23 Thread Django

#6928: commit_on_success: Handle KeyboardInterrupt
-+-
   Reporter:  guettli|  Owner:  nobody
   Type: | Status:  closed
  Uncategorized  |  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   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 mtredinnick):

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


Comment:

 The issue in this ticket was closed long ago. The new comment refers to a
 new issue, so I have created ticket #16682 for that. Closing this 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.

[Django] #16682: KeyboardInterrupt not handled properly in transaction aborting

2011-08-23 Thread Django

#16682: KeyboardInterrupt not handled properly in transaction aborting
-+-
 Reporter:  mtredinnick  |Owner:  nobody
 Type:  Bug  |   Status:  new
Milestone:   |Component:  Database
  Version:  1.3  |  layer (models, ORM)
 Keywords:   | Severity:  Normal
Has patch:  0| Triage Stage:
  Needs tests:  0|  Unreviewed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
 Ticket #6928 was reopened to report this, so I (Malcolm) am moving it to a
 new ticket, since it's a separate issue. Following text is from comment:7
 on that ticket:

 ---

 After [14288] transaction.commit_on_success does not handle
 `KeyboardInterrupt`.

 Problem in `django.db.transaction.Transaction.__exit__` and default
 `exiting` function.

 {{{#!python
 def __exit__(self, exc_type, exc_value, traceback):
 self.exiting(exc_value, self.using)
 }}}

 `exc_value` is None after `KeyboardInterrupt` has been throwed, only
 `exc_type` and `traceback` has value.
 But if raise `KeyboardInterrupt` manualy from code it's work ok.

 Possible solution: use `exc_type` and `exc_value` in `exiting` function

 I use python 2.6.6

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

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

2011-08-23 Thread Django

#16202: Localflavor support for Slovenia (si)
-+-
   Reporter:  Jure   |  Owner:  nobody
  Cuhalev | Status:  reopened
   Type:  New|  Component:  contrib.localflavor
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by iElectric):

 Seems like last line was stripped. Should current patch be updated or
 create new one on top of 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] #13165: Display edit link beside add button for ForeignKey fields in admin

2011-08-23 Thread Django

#13165: Display edit link beside add button for ForeignKey fields in admin
-+-
   Reporter:  DrMeers|  Owner:  DrMeers
   Type:  New| Status:  reopened
  feature|  Component:  contrib.admin
  Milestone:  1.3|   Severity:  Normal
Version:  SVN|   Keywords:  admin foreign key
 Resolution: |  edit link
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  1  |
-+-
Changes (by anonymous):

 * easy:   => 0


Comment:

 Hi - I'm just about to start hacking something like this together... any
 idea when it might make it into trunk? If there is anything useful I can
 do...

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

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

2011-08-23 Thread Django

#16202: Localflavor support for Slovenia (si)
-+-
   Reporter:  Jure   |  Owner:  nobody
  Cuhalev | Status:  reopened
   Type:  New|  Component:  contrib.localflavor
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by jonash):

 `test_SIPostalCodeSelect` doesn't test anything, btw. (See
 
https://code.djangoproject.com/browser/django/trunk/tests/regressiontests/forms/localflavor/si.py?rev=16662#L90)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15497: BooleanField should work for all PostgreSQL expressions

2011-08-23 Thread Django

#15497: BooleanField should work for all PostgreSQL expressions
-+-
   Reporter:  lsaffre|  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by lsaffre):

 As reporter I also meanwhile think it's better to leave `BooleanField`
 unchanged. I'd just change the docstring of `Field.to_python` to make
 clear that it parses only SQL statements (but for all supported db
 backends).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16130: Add some information about admin media in staticfiles documentation

2011-08-23 Thread Django

#16130: Add some information about admin media in staticfiles documentation
-+-
   Reporter:  aroy   |  Owner:  kman
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  invalid|  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 I'm not sure if that's a good idea, `ADMIN_MEDIA_PREFIX` was removed in
 trunk after all.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16134: django.db.models.fields.Field instance can not be compared with None

2011-08-23 Thread Django

#16134: django.db.models.fields.Field instance can not be compared with None
-+-
   Reporter:  amcharg@…  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  1
-+-
Changes (by mtredinnick):

 * ui_ux:   => 0
 * stage:  Ready for checkin => Accepted


Comment:

 Hmm... I'm a little unclear on the use-case for this. Instantiating fields
 is internal to Django -- normal models expose Python attributes and the
 Field instances are hidden in the Meta class (which is opaque). Making
 this change "just because we can" isn't necessary. What's the normal code
 pattern that triggers a problem here?

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

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

Re: [Django] #16678: Write tests for django.contrib.redirects

2011-08-23 Thread Django

#16678: Write tests for django.contrib.redirects
-+-
   Reporter:  julien |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.redirects
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #16655: Silent error in ModelAdmin.list_display callables...

2011-08-23 Thread Django

#16655: Silent error in ModelAdmin.list_display callables...
+---
   Reporter:  jedie |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
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:  0
  UI/UX:  0 |
+---

Comment (by jedie):

 Replying to [comment:2 aaugustin]:
 > Finally, regarding the test that seems wrong to you, could you open a
 separate ticket?

 IMHO the two things are related. Both should be changed together, isn't
 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] #16460: Add support for Index Length for MySQL-backed Models

2011-08-23 Thread Django

#16460: Add support for Index Length for MySQL-backed Models
-+-
   Reporter:  umbrae@…   |  Owner:  nobody
   Type:  New| Status:  closed
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution:  invalid|   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by mtredinnick):

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


Comment:

 Adding database specific attributes to Field classes isn't an option. We
 already allow initial SQL as well as emitting a syncdb signal that can be
 used for just this purpose: custom creation SQL insertion. That is where
 you would put code to create the appropriate index.

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

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

2011-08-23 Thread Django

#16202: Localflavor support for Slovenia (si)
-+-
   Reporter:  Jure   |  Owner:  nobody
  Cuhalev | Status:  reopened
   Type:  New|  Component:  contrib.localflavor
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by russellm):

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


Comment:

 In [16669]: There are a bunch of problems with this patch that I didn't
 pick up at time of commit -- tests don't pass, and it doesn't reflect some
 recent changes in the testing tools. Patch needs to be updated.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r16669 - in django/trunk: django/contrib/localflavor docs/ref/contrib docs/releases tests/regressiontests/forms tests/regressiontests/forms/localflavor tests/regressiontests/forms/tests

2011-08-23 Thread noreply

Author: russellm
Date: 2011-08-22 23:31:03 -0700 (Mon, 22 Aug 2011)
New Revision: 16669

Removed:
   django/trunk/django/contrib/localflavor/si/
   django/trunk/tests/regressiontests/forms/localflavor/si.py
Modified:
   django/trunk/docs/ref/contrib/localflavor.txt
   django/trunk/docs/releases/1.4.txt
   django/trunk/tests/regressiontests/forms/localflavortests.py
   django/trunk/tests/regressiontests/forms/tests/__init__.py
Log:
Reverted r16662 -- There are bunch of problems with this patch, including 
failing tests, that I didn't pick up before committing.

Modified: django/trunk/docs/ref/contrib/localflavor.txt
===
--- django/trunk/docs/ref/contrib/localflavor.txt   2011-08-23 06:29:01 UTC 
(rev 16668)
+++ django/trunk/docs/ref/contrib/localflavor.txt   2011-08-23 06:31:03 UTC 
(rev 16669)
@@ -70,7 +70,6 @@
 * Romania_
 * Russia_
 * Slovakia_
-* Slovenia_
 * `South Africa`_
 * Spain_
 * Sweden_
@@ -127,7 +126,6 @@
 .. _Romania: `Romania (ro)`_
 .. _Russia: `Russia (ru)`_
 .. _Slovakia: `Slovakia (sk)`_
-.. _Slovenia: `Slovenia (si)`_
 .. _South Africa: `South Africa (za)`_
 .. _Spain: `Spain (es)`_
 .. _Sweden: `Sweden (se)`_
@@ -1070,35 +1068,6 @@
 
 A ``Select`` widget that uses a list of Slovak regions as its choices.
 
-Slovenia (``si``)
-=
-
-.. class:: si.forms.SIEMSOField
-
-A form field that validates input as Slovenian personal identification
-number and stores gender and birthday to self.info dictionary.
-
-.. class:: si.forms.SITaxNumberField
-
-A form field that validates input as a Slovenian tax number. Valid input
-is SI or .
-
-.. class:: si.forms.SIPhoneNumberField
-
-A form field that validates input as a Slovenian phone number. Phone
-number must contain at least local area code with optional country code.
-
-.. class:: si.forms.SIPostalCodeField
-
-A form field that provides a choice field of major Slovenian postal
-codes.
-
-.. class:: si.forms.SIPostalCodeSelect
-
-A ``Select`` widget that uses a list of major Slovenian postal codes as
-its choices.
-
-
 South Africa (``za``)
 =
 

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2011-08-23 06:29:01 UTC (rev 16668)
+++ django/trunk/docs/releases/1.4.txt  2011-08-23 06:31:03 UTC (rev 16669)
@@ -235,11 +235,6 @@
 See the :class:`~django.contrib.staticfiles.storage.CachedStaticFilesStorage`
 docs for more information.
 
-Localflavor changes
-~~~
-
- * A Slovenian (si) localflavor was added.
-
 Minor features
 ~~
 

Deleted: django/trunk/tests/regressiontests/forms/localflavor/si.py
===
--- django/trunk/tests/regressiontests/forms/localflavor/si.py  2011-08-23 
06:29:01 UTC (rev 16668)
+++ django/trunk/tests/regressiontests/forms/localflavor/si.py  2011-08-23 
06:31:03 UTC (rev 16669)
@@ -1,556 +0,0 @@
-# -*- coding: utf-8 -*-
-
-from datetime import date
-
-from django.contrib.localflavor.si.forms import (SIEMSOField, SITaxNumberField,
-SIPhoneNumberField, SIPostalCodeField, SIPostalCodeSelect)
-
-from utils import LocalFlavorTestCase
-
-
-class SILocalFlavorTests(LocalFlavorTestCase):
-def test_SITaxNumberField(self):
-error_invalid = [u'Enter a valid tax number in form SI']
-valid = {
-'15012557': '15012557',
-'SI15012557': '15012557',
-'22111310': '22111310',
-}
-invalid = {
-'22241310': error_invalid,
-'15012558': error_invalid,
-'1501': error_invalid,
-'1501123123123': error_invalid,
-'abcdabcd': error_invalid,
-'01234579': error_invalid,
-}
-self.assertFieldOutput(SITaxNumberField, valid, invalid)
-
-def test_SIEMSOField(self):
-error_invalid = [u'This field should contain exactly 13 digits.']
-error_invalid_date = [u'The first 7 digits of the EMSO must represent 
a valid past date.']
-error_invalid_chksum = [u'The EMSO is not valid.']
-valid = {
-'0205951500462': '0205951500462',
-'2309002500068': '2309002500068',
-'1010985500400': '1010985500400',
-}
-invalid = {
-'0205951500463': error_invalid_chksum,
-'020': error_invalid,
-'020020595150046020595150046': error_invalid,
-'d': error_invalid,
-'1010985500800': error_invalid_chksum,
-'2020095500070': error_invalid_date,
-'5050095500078': error_invalid_date,
-'1010889500408': error_invalid_date,
-}
-self.assertFieldOutput(SIEMSOField, valid, invalid)
-
-def test_SIEMSOField_info_dict(self):
-valid = {
-

[Changeset] r16668 - in django/trunk: django/db/models/sql tests/modeltests/defer

2011-08-23 Thread noreply

Author: mtredinnick
Date: 2011-08-22 23:29:01 -0700 (Mon, 22 Aug 2011)
New Revision: 16668

Modified:
   django/trunk/django/db/models/sql/query.py
   django/trunk/tests/modeltests/defer/tests.py
Log:
Allow "pk" as a field alias in QuerySet.only() calls.

Thanks to GDorn for the patch. Fixed #15494.

Modified: django/trunk/django/db/models/sql/query.py
===
--- django/trunk/django/db/models/sql/query.py  2011-08-23 06:28:45 UTC (rev 
16667)
+++ django/trunk/django/db/models/sql/query.py  2011-08-23 06:29:01 UTC (rev 
16668)
@@ -1791,13 +1791,18 @@
 existing immediate values, but respects existing deferrals.)
 """
 existing, defer = self.deferred_loading
+field_names = set(field_names)
+if 'pk' in field_names:
+field_names.remove('pk')
+field_names.add(self.model._meta.pk.name)
+
 if defer:
 # Remove any existing deferred names from the current set before
 # setting the new names.
-self.deferred_loading = set(field_names).difference(existing), 
False
+self.deferred_loading = field_names.difference(existing), False
 else:
 # Replace any existing "immediate load" field names.
-self.deferred_loading = set(field_names), False
+self.deferred_loading = field_names, False
 
 def get_loaded_field_names(self):
 """

Modified: django/trunk/tests/modeltests/defer/tests.py
===
--- django/trunk/tests/modeltests/defer/tests.py2011-08-23 06:28:45 UTC 
(rev 16667)
+++ django/trunk/tests/modeltests/defer/tests.py2011-08-23 06:29:01 UTC 
(rev 16668)
@@ -28,11 +28,18 @@
 self.assert_delayed(qs.only("name")[0], 2)
 self.assert_delayed(qs.defer("related__first")[0], 0)
 
+# Using 'pk' with only() should result in 3 deferred fields, namely all
+# of them except the model's primary key see #15494
+self.assert_delayed(qs.only("pk")[0], 3)
+
 obj = qs.select_related().only("related__first")[0]
 self.assert_delayed(obj, 2)
 
 self.assertEqual(obj.related_id, s1.pk)
 
+# You can use 'pk' with reverse foreign key lookups.
+self.assert_delayed(s1.primary_set.all().only('pk')[0], 3)
+
 self.assert_delayed(qs.defer("name").extra(select={"a": 1})[0], 1)
 self.assert_delayed(qs.extra(select={"a": 1}).defer("name")[0], 1)
 self.assert_delayed(qs.defer("name").defer("value")[0], 2)
@@ -135,3 +142,4 @@
 self.assertEqual(obj.other, "bar")
 obj.name = "bb"
 obj.save()
+

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

Re: [Django] #15494: Using only('pk') in related set raises FieldDoesNotExist

2011-08-23 Thread Django

#15494: Using only('pk') in related set raises FieldDoesNotExist
-+-
   Reporter:  anonymous  |Owner:  GDorn
   Type:  Bug|   Status:  closed
  Milestone: |Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution:  fixed  | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:
Needs documentation:  0  |Has patch:  1
Patch needs improvement:  1  |  Needs tests:  1
-+-
Changes (by mtredinnick):

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


Comment:

 In [16668]:
 {{{
 #!CommitTicketReference repository="" revision="16668"
 Allow "pk" as a field alias in QuerySet.only() calls.

 Thanks to GDorn for the patch. Fixed #15494.
 }}}

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

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

2011-08-23 Thread noreply

Author: mtredinnick
Date: 2011-08-22 23:28:45 -0700 (Mon, 22 Aug 2011)
New Revision: 16667

Modified:
   django/trunk/tests/regressiontests/queries/models.py
Log:
Fixed a broken test from r16656.

Modified: django/trunk/tests/regressiontests/queries/models.py
===
--- django/trunk/tests/regressiontests/queries/models.py2011-08-23 
06:00:08 UTC (rev 1)
+++ django/trunk/tests/regressiontests/queries/models.py2011-08-23 
06:28:45 UTC (rev 16667)
@@ -319,13 +319,13 @@
return self.name
 
 class SimpleCategory(models.Model):
-name = models.CharField(max_length=10)
+name = models.CharField(max_length=15)
 
 def __unicode__(self):
 return self.name
 
 class SpecialCategory(SimpleCategory):
-special_name = models.CharField(max_length=10)
+special_name = models.CharField(max_length=15)
 
 def __unicode__(self):
 return self.name + " " + self.special_name
@@ -337,9 +337,9 @@
return "category item: " + str(self.category)
 
 class OneToOneCategory(models.Model):
-new_name = models.CharField(max_length=10)
+new_name = models.CharField(max_length=15)
 category = models.OneToOneField(SimpleCategory)
 
 def __unicode__(self):
 return "one2one " + self.new_name
-
\ No newline at end of file
+

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

Re: [Django] #16458: Equality operator on django.db.models.Model not commutative

2011-08-23 Thread Django

#16458: Equality operator on django.db.models.Model not commutative
-+-
   Reporter: |  Owner:  teraom
  freek.wiekmeijer@… | Status:  assigned
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by mtredinnick):

 * needs_better_patch:  0 => 1


Comment:

 Russell and I talked about this and we think derived classes can be equal
 to the parent if the pk's are the same. Model inheritance in Django is
 *not* the same as class inheritance in Python, because you can never have
 an instance of just the super class in Python (amongst many other
 differences), so there's no completely parallel case to compare with. It's
 useful for the derived class to be comparable to the parent instance
 because (by design) queries only return the parent instance and there are
 cases for wanting to check if we already have something when we have the
 derived class instance.

 Deferred and proxy objects should be equal to their non-deferred, non-
 proxy things. Basically, we are comparing things as a bag of data (without
 respect to data that might be missing due to being in a subclass instance
 if the parent was extended to the subclass). This is consistent with a
 reasonable "equal" and utilises the fact that equality is not the same as
 object identity.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r16666 - django/branches/releases/1.3.X/docs/intro

2011-08-23 Thread noreply

Author: julien
Date: 2011-08-22 23:00:08 -0700 (Mon, 22 Aug 2011)
New Revision: 1

Modified:
   django/branches/releases/1.3.X/docs/intro/tutorial02.txt
Log:
[1.3.X] Fixed #16680 -- Used single quotes for the TEMPLATE_DIRS examples in 
part 2 of the tutorial to be consistent with the settings.py file generated by 
the startproject command. Thanks, Michael Tomkins.

Backport of r16660 from trunk.

Modified: django/branches/releases/1.3.X/docs/intro/tutorial02.txt
===
--- django/branches/releases/1.3.X/docs/intro/tutorial02.txt2011-08-23 
05:59:54 UTC (rev 16665)
+++ django/branches/releases/1.3.X/docs/intro/tutorial02.txt2011-08-23 
06:00:08 UTC (rev 1)
@@ -405,14 +405,14 @@
 tell Django where our templates live::
 
 TEMPLATE_DIRS = (
-"/home/my_username/mytemplates", # Change this to your own directory.
+'/home/my_username/mytemplates', # Change this to your own directory.
 )
 
 Now copy the template ``admin/base_site.html`` from within the default Django
 admin template directory in the source code of Django itself
 (``django/contrib/admin/templates``) into an ``admin`` subdirectory of
 whichever directory you're using in :setting:`TEMPLATE_DIRS`. For example, if
-your :setting:`TEMPLATE_DIRS` includes ``"/home/my_username/mytemplates"``, as
+your :setting:`TEMPLATE_DIRS` includes ``'/home/my_username/mytemplates'``, as
 above, then copy ``django/contrib/admin/templates/admin/base_site.html`` to
 ``/home/my_username/mytemplates/admin/base_site.html``. Don't forget that
 ``admin`` subdirectory.

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

2011-08-23 Thread Django

#16680: Inconsistant use of " and '
-+-
   Reporter: |  Owner:  nobody
  michaeltomkins | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  quotes consistency
Version:  SVN|  documentation tutorial
 Resolution:  fixed  |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by julien):

 In [1]:
 {{{
 #!CommitTicketReference repository="" revision="1"
 [1.3.X] Fixed #16680 -- Used single quotes for the TEMPLATE_DIRS examples
 in part 2 of the tutorial to be consistent with the settings.py file
 generated by the startproject command. Thanks, Michael Tomkins.

 Backport of r16660 from trunk.
 }}}

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

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

[Changeset] r16665 - django/branches/releases/1.3.X/docs/intro

2011-08-23 Thread noreply

Author: julien
Date: 2011-08-22 22:59:54 -0700 (Mon, 22 Aug 2011)
New Revision: 16665

Modified:
   django/branches/releases/1.3.X/docs/intro/tutorial01.txt
Log:
[1.3.X] Fixed #16669 -- Made the startproject instruction formatting easier to 
read and more consistent with other formatting in the tutorial part 1. Thanks 
to Daniel Lawrence and Aymeric Augustin.

Backport of r16664 from trunk.

Modified: django/branches/releases/1.3.X/docs/intro/tutorial01.txt
===
--- django/branches/releases/1.3.X/docs/intro/tutorial01.txt2011-08-23 
05:24:31 UTC (rev 16664)
+++ django/branches/releases/1.3.X/docs/intro/tutorial01.txt2011-08-23 
05:59:54 UTC (rev 16665)
@@ -36,9 +36,14 @@
 application-specific settings.
 
 From the command line, ``cd`` into a directory where you'd like to store your
-code, then run the command ``django-admin.py startproject mysite``. This will
-create a ``mysite`` directory in your current directory.
+code, then run the following command:
 
+.. code-block:: bash
+
+   django-admin.py startproject mysite
+   
+This will create a ``mysite`` directory in your current directory.
+
 .. admonition:: Script name may differ in distribution packages
 
If you installed Django using a Linux distribution's package manager

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

66 matches

Mail list logo