Re: [Django] #26126: Transient failure of requests.tests.RequestsTests.test_max_age_expiration

2016-02-11 Thread Django
#26126: Transient failure of 
requests.tests.RequestsTests.test_max_age_expiration
-+-
 Reporter:  charettes|Owner:
 Type:   |  berkerpeksag
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by berkerpeksag):

 * cc: berker.peksag@… (added)
 * owner:  nobody => berkerpeksag
 * has_patch:  0 => 1
 * status:  new => assigned


Comment:

 Pull request: https://github.com/django/django/pull/6130

 Alternative solutions:

 * Make assertEqual check less strict: Don't check for the exact return
 value of `cookie_date()`.
 * Convert assertEqual to assertIn and check if the return value is
 `time.time() + 10 + 1` or `time.time() + 10 - 1`. This is simpler than the
 first solution.
 * Mock `cookie_date()` in `HttpResponseBase.set_cookie()`.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.416769a2c0653db1190914c8b0e6f9d6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26212: Forms' FileField is not pickleable

2016-02-11 Thread Django
#26212: Forms' FileField is not pickleable
-+--
 Reporter:  koterpillar  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.9
 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 koterpillar):

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


Comment:

 [https://github.com/django/django/pull/6128 PR]

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.aad82dcb418d4751e471d22da2cef2e9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25759: Add **kwargs to as_sql method of Expressions

2016-02-11 Thread Django
#25759: Add **kwargs to as_sql method of Expressions
-+-
 Reporter:  jarshwah |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  expressions  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by jarshwah):

 * easy:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.c65cc1297c2029f532207632c68ec3ba%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26212: Forms' FileField is not pickleable

2016-02-11 Thread Django
#26212: Forms' FileField is not pickleable
-+
 Reporter:  koterpillar  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Forms|Version:  1.9
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 In Django 1.6 through to 1.9 and current HEAD, FileField cannot be pickled
 though other form fields can.

 Steps to reproduce:

 {{{
 #!python
 import pickle
 from django import forms
 pickle.dumps(forms.FileField())
 }}}

 On 1.5.x, this succeeds, but 1.6 through to 1.9 fail:

 {{{
 PicklingError: Can't pickle  at 0x7faab4f2cde8>: it's
 not found as django.utils.translation.
 }}}

 See #17976 for a similar problem with BooleanField.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.e01e1452bc6d44667f2d0fff9a8a5708%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25687: Document how backends should monkey patch expressions

2016-02-11 Thread Django
#25687: Document how backends should monkey patch expressions
-+-
 Reporter:  jarshwah |Owner:
 Type:   |  kristofclaes
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 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 timgraham):

 * easy:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.7aed112852a41083705ae17c3172ca85%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26211: prefetch_related with Prefetch with queryset with explicit Ordering Ignored

2016-02-11 Thread Django
#26211: prefetch_related with Prefetch with queryset with explicit Ordering 
Ignored
-+-
 Reporter:  cancan101|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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 charettes):

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


Comment:

 I'm also inclined to close this ticket as expected behavior.

 The `prefetch_related` method stores the prefetched objects on the
 instance it belongs to. As soon as you call a queryset method on the
 related manager holding the cached instances (`child_set.order_by()`) a
 new queryset instance is returned which doesn't hold any reference to the
 previously cached results.

 This is same as expecting a call to a queryset method with cached results
 to perform its operation in memory instead of going back to the db.

 e.g.

 {{{#!python
 children = Child.objects.all()
 list(children)  # Will issue a query and cache the results on the children
 objects.
 list(children)  # Will reuse the cached results.
 children.order_by('saved_dt')  # Will perform a new database query even if
 children has cached results.
 }}}

 If we performed the operation in memory this could lead to catastrophic
 performance given a large enough result set. This would be backward
 incompatible and kind of a footgun API.

 I think the `Queryset` documentation makes it clear that calling a method
 will create and return a new instance with no cached results.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ddffd37162eeba877c93cd39d38f8113%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25251: Inconsistent availability of data migrations in TransactionTestCase when using --keepdb

2016-02-11 Thread Django
#25251: Inconsistent availability of data migrations in TransactionTestCase when
using --keepdb
---+
 Reporter:  davidszotten   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.8
 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 timgraham):

 If you could submit a patch with that approach along with a regression
 test, I'll take a closer look.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.031fdba489139b52763a7d0c5902ff1a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26111: Clarify that fixture loading for TestCase is per test case

2016-02-11 Thread Django
#26111: Clarify that fixture loading for TestCase is per test case
-+-
 Reporter:  karyon   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"6a0832dacbe185fbd9e172797dd15a26b9e26943" 6a0832da]:
 {{{
 #!CommitTicketReference repository=""
 revision="6a0832dacbe185fbd9e172797dd15a26b9e26943"
 [1.9.x] Fixed #26111 -- Clarified that fixtures are loaded once per
 TestCase.

 Backport of 02430ef19d9a7d3663cbc1cf66438e9e86b919d1 from master
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.d6b5185c06afc5cc9b7d597eb44ceffb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26111: Clarify that fixture loading for TestCase is per test case

2016-02-11 Thread Django
#26111: Clarify that fixture loading for TestCase is per test case
-+-
 Reporter:  karyon   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"02430ef19d9a7d3663cbc1cf66438e9e86b919d1" 02430ef]:
 {{{
 #!CommitTicketReference repository=""
 revision="02430ef19d9a7d3663cbc1cf66438e9e86b919d1"
 Fixed #26111 -- Clarified that fixtures are loaded once per TestCase.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.29d7525a16cf3b4f115f5baf4293bb4d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26211: prefetch_related with Prefetch with queryset with explicit Ordering Ignored

2016-02-11 Thread Django
#26211: prefetch_related with Prefetch with queryset with explicit Ordering 
Ignored
-+-
 Reporter:  cancan101|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 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 timgraham):

 * type:  Uncategorized => New feature
 * component:  Uncategorized => Database layer (models, ORM)


Comment:

 I disagree -- enabling `QuerySet.order_by()` to sometimes do operations in
 memory could be quite confusing. I think this has probably been proposed
 before in some form before, but can't immediately find a discussion. As
 [https://docs.djangoproject.com/en/stable/ref/models/querysets/ the
 documentation] notes, "Each `order_by()` call will clear any previous
 ordering" (it returns a new `QuerySet`). Anyway, this isn't my area of
 expertise so I'll leave it open for a second opinion.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.9740fe93d1b61dd8ad9151546826604d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26111: Clarify that fixture loading for TestCase is per test case

2016-02-11 Thread Django
#26111: Clarify that fixture loading for TestCase is per test case
-+-
 Reporter:  karyon   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

 [https://github.com/django/django/pull/6126 PR]

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.0d962ec93f901aebbf2746987e3e0529%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26211: prefetch_related with Prefetch with queryset with explicit Ordering Ignored

2016-02-11 Thread Django
#26211: prefetch_related with Prefetch with queryset with explicit Ordering 
Ignored
---+--
 Reporter:  cancan101  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.9
 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 cancan101):

 Woah! I was not suggesting closing this! I don't think behavior is as
 expected. The ORM should realize the prefetch has already been done.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6d11b5ec86e15f7abfeba895ff7ddb0e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26211: prefetch_related with Prefetch with queryset with explicit Ordering Ignored

2016-02-11 Thread Django
#26211: prefetch_related with Prefetch with queryset with explicit Ordering 
Ignored
---+--
 Reporter:  cancan101  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.9
 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 timgraham):

 Good, that's what I was going suggest. I think we can close this as
 expected behavior.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.5f8a9df1fa8a9c0721e61782cb69600a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #20468: loaddata - during import exclude some applications

2016-02-11 Thread Django
#20468: loaddata - during import exclude some applications
-+-
 Reporter:  fizista  |Owner:
 |  alexmorozov
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.04c282da9487e5e82a9756b913fd9c97%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26211: prefetch_related with Prefetch with queryset with explicit Ordering Ignored

2016-02-11 Thread Django
#26211: prefetch_related with Prefetch with queryset with explicit Ordering 
Ignored
---+--
 Reporter:  cancan101  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.9
 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 cancan101):

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


Comment:

 If I remove the `order_by` on the `m.child_set`, then I get the expected
 two queries:


 {{{
 [m.child_set.all()  for m in
 Parent.objects.prefetch_related(Prefetch('child_set',
 Child.objects.order_by('saved_dt'))).all()]

 SELECT "prefetch_parent"."id" FROM "prefetch_parent"; args=()
 SELECT "prefetch_child"."id", "prefetch_child"."saved_dt",
 "prefetch_child"."parent_id" FROM "prefetch_child" WHERE
 "prefetch_child"."parent_id" IN (1, 2) ORDER BY
 "prefetch_child"."saved_dt" ASC; args=(1, 2)
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6dc1d664206481f4ae018ce4a9a0976f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26209: Hide lowercase sensitive setting

2016-02-11 Thread Django
#26209: Hide lowercase sensitive setting
-+-
 Reporter:  francoisfreitag  |Owner:
 |  francoisfreitag
 Type:  New feature  |   Status:  closed
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"16a88b4429eb237cf3f7df6526c072efb72dbed1" 16a88b44]:
 {{{
 #!CommitTicketReference repository=""
 revision="16a88b4429eb237cf3f7df6526c072efb72dbed1"
 Fixed #26209 -- Masked sensitive settings in debug reports regardless of
 case.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.47935babce950f96385a8f41e8fb4caf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26211: prefetch_related with Prefetch with queryset with explicit Ordering Ignored

2016-02-11 Thread Django
#26211: prefetch_related with Prefetch with queryset with explicit Ordering 
Ignored
---+
 Reporter:  cancan101  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Given these models:

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

 class Child(models.Model):
 saved_dt = models.DateTimeField(auto_now_add=True)
 parent = models.ForeignKey(Parent)
 }}}

 I am executing this query (for each `Parent` I want to get the `child_set`
 in sorted order):

 {{{
 [m.child_set.order_by('saved_dt') for m in
 Parent.objects.prefetch_related(Prefetch('child_set',
 Child.objects.order_by('saved_dt'))).all()]
 }}}

 I would expect that to be two SQL queries, but in reality I see `N+2`
 where `N` is the number of `Child`s:


 {{{
 SELECT "prefetch_parent"."id" FROM "prefetch_parent"; args=()
 SELECT "prefetch_child"."id", "prefetch_child"."saved_dt",
 "prefetch_child"."parent_id" FROM "prefetch_child" WHERE
 "prefetch_child"."parent_id" IN (1, 2) ORDER BY
 "prefetch_child"."saved_dt" ASC; args=(1, 2)
 SELECT "prefetch_child"."id", "prefetch_child"."saved_dt",
 "prefetch_child"."parent_id" FROM "prefetch_child" WHERE
 "prefetch_child"."parent_id" = 1 ORDER BY "prefetch_child"."saved_dt" ASC
 LIMIT 21; args=(1,)
 SELECT "prefetch_child"."id", "prefetch_child"."saved_dt",
 "prefetch_child"."parent_id" FROM "prefetch_child" WHERE
 "prefetch_child"."parent_id" = 2 ORDER BY "prefetch_child"."saved_dt" ASC
 LIMIT 21; args=(2,)
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.b3b45ff9727298aa2b8825c67cfc1e18%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26209: Hide lowercase sensitive setting

2016-02-11 Thread Django
#26209: Hide lowercase sensitive setting
-+-
 Reporter:  francoisfreitag  |Owner:
 |  francoisfreitag
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by francoisfreitag):

 * needs_tests:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.e2f17bf042744f876bc3a02135bc45e9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #11665: django.test.TestCase should flush constraints

2016-02-11 Thread Django
#11665: django.test.TestCase should flush constraints
---+
 Reporter:  Glenn  |Owner:
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by jdufresne):

 * needs_better_patch:  1 => 0


Comment:

 I have addressed all comments in the PR. Please let me know if you have
 any additional feedback. Thanks.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.c5432b213d18e1c95b2075811a2b22b2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25850: Migrations ignore inconsistent history silently

2016-02-11 Thread Django
#25850: Migrations ignore inconsistent history silently
--+
 Reporter:  shaib |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Uran198):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.8ed36caf3782410b5bfff091e8a921ec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25251: Inconsistent availability of data migrations in TransactionTestCase when using --keepdb

2016-02-11 Thread Django
#25251: Inconsistent availability of data migrations in TransactionTestCase when
using --keepdb
---+
 Reporter:  davidszotten   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.8
 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 romgar):

 I'm facing the same problem: my initial data are no more in the database
 at the end of my test suite, even with `--keepdb` option.
 As `TransactionTestCase` is always flushing data on the `tearDown`, why
 not reloading the serialized data after the flush, instead of on the
 `setUp` step ?
 I have tried a naive approach by moving the logic related  to string
 serialized data loading on the `tearDown` step,
 
https://github.com/romgar/django/commit/7219308cf8f196463d03d1407b0ad0e9b918a3db
 and the data is then kept.
 Not really sure about any other impact anywhere else.
 I run the django test suite without any failure.
 Any feedbacks on that ?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.7d9290a361ec8374b4cdb2b787bbfa79%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26208: Squashing migrations in which unique=True is added and then removed for Charfield cannot migrate backwards on Postgres

2016-02-11 Thread Django
#26208: Squashing migrations in which unique=True is added and then removed  for
Charfield cannot migrate backwards on Postgres
-+-
 Reporter:  linuss   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  migrations squash| Triage Stage:
  charfield unique   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 I followed those steps but couldn't reproduce. Could list the exact
 commands for each step to ensure I didn't misinterpret?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.fb2dd0eecba1a97e267f2bb00863b085%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26210: When emailing the admins about exceptions and an error occurs, it continues as if there had been no error

2016-02-11 Thread Django
#26210: When emailing the admins about exceptions and an error occurs, it 
continues
as if there had been no error
-+--
 Reporter:  aptiko   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.9
 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 timgraham):

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


Comment:

 This looks like intentional behavior as described in #19637. I'm not sure
 what change we could make other than document it. Do you have a proposal?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.6bcfc303e7f7a76606d247514d7531b0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26196: Django 1.9 ORM generates invalid subqueries for FK fields with 'to_field'

2016-02-11 Thread Django
#26196: Django 1.9 ORM generates invalid subqueries for FK fields with 
'to_field'
-+-
 Reporter:  hellpain |Owner:  charettes
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"1d9ee181fe09a5c3784bbbf802cc522f11ff25ef" 1d9ee18]:
 {{{
 #!CommitTicketReference repository=""
 revision="1d9ee181fe09a5c3784bbbf802cc522f11ff25ef"
 [1.9.x] Fixed #26196 -- Made sure __in lookups use to_field as default.

 Thanks Simon Charette for the test.

 Backport of 46ecfb9b3a11a360724e3375ba78c33c46d6a992 from master
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.2f822f09688ea1bf68195159ae4b0a79%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26196: Django 1.9 ORM generates invalid subqueries for FK fields with 'to_field'

2016-02-11 Thread Django
#26196: Django 1.9 ORM generates invalid subqueries for FK fields with 
'to_field'
-+-
 Reporter:  hellpain |Owner:  charettes
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"46ecfb9b3a11a360724e3375ba78c33c46d6a992" 46ecfb9b]:
 {{{
 #!CommitTicketReference repository=""
 revision="46ecfb9b3a11a360724e3375ba78c33c46d6a992"
 Fixed #26196 -- Made sure __in lookups use to_field as default.

 Thanks Simon Charette for the 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.fb65e5e9e3e228b594e38f3b6ee583e8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26204: URLValidator does not accept TLDs with "-"s

2016-02-11 Thread Django
#26204: URLValidator does not accept TLDs with "-"s
--+-
 Reporter:  lfaraone  |Owner:  timgraham
 Type:  Bug   |   Status:  assigned
Component:  Core (Other)  |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:  regression| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/6123 PR]

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.325029a2d8712ba176343575b24964e0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26204: URLValidator does not accept TLDs with "-"s

2016-02-11 Thread Django
#26204: URLValidator does not accept TLDs with "-"s
--+-
 Reporter:  lfaraone  |Owner:  timgraham
 Type:  Bug   |   Status:  assigned
Component:  Core (Other)  |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:  regression| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by timgraham):

 * status:  new => assigned
 * owner:  nobody => timgraham
 * component:  Uncategorized => Core (Other)
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.6b60540b031cf5b06dcac853792807db%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26209: Hide lowercase sensitive setting

2016-02-11 Thread Django
#26209: Hide lowercase sensitive setting
-+-
 Reporter:  francoisfreitag  |Owner:
 |  francoisfreitag
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by timgraham):

 Okay, please uncheck "Needs tests" on this ticket when you add one to the
 pull request. Thanks.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.0d4cfd1787798829d7215df195a18f7a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26179: Remove null assignment check for non-nullable foreign key fields

2016-02-11 Thread Django
#26179: Remove null assignment check for non-nullable foreign key fields
-+-
 Reporter:  timgraham|Owner:
 Type:   |  ZachLiuGIS
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"04e13c89138d48c20e774a2b6bf06796f73ac0fe" 04e13c8]:
 {{{
 #!CommitTicketReference repository=""
 revision="04e13c89138d48c20e774a2b6bf06796f73ac0fe"
 Fixed #26179 -- Removed null assignment check for non-nullable foreign key
 fields.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.67d759bbcee5c4c5d72ded5265eb8d53%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26210: When emailing the admins about exceptions and an error occurs, it continues as if there had been no error

2016-02-11 Thread Django
#26210: When emailing the admins about exceptions and an error occurs, it 
continues
as if there had been no error
-+
 Reporter:  aptiko   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (Mail)  |Version:  1.9
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 My server had a 500 error, and Django was trying to email the error
 information to the ADMINS. Upon reaching
 
https://github.com/django/django/blob/0ed7d15/django/core/mail/backends/smtp.py#L64,
 there was an exception because of a gevent bug.

 In that case, `fail_silently` is True. The result is that the `open()`
 method returns as if everything had gone fine. This means that,
 subsequently, the `send_messages()` method will be called, and so on.

 Impact: Maybe this is just a bit ugly, however if you continue to work as
 if there had been no error when an error has actually occurred, you are
 asking for trouble. http://stackoverflow.com/questions/35315397/ shows why
 this issue made debugging another problem a day or two longer.

 It should also be possible to log the error that occurs during the sending
 of the email, although this is probably a different issue.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.4774b6672c11fdc9ee42bfd7ddd0325f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26209: Hide lowercase sensitive setting

2016-02-11 Thread Django
#26209: Hide lowercase sensitive setting
-+-
 Reporter:  francoisfreitag  |Owner:
 |  francoisfreitag
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by francoisfreitag):

 That's correct. Something like this was defined:
 {{{#!python
 RABBITMQ = {
 'host': 'localhost',
 'login': 'guest',
 'password': 'guest',
 }
 }}}
 I was surprised to see that `DATABASES` password was hidden, but not
 `RABBITMQ`.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.1bda67a30f055c71192b04cea9754286%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26153: Allow get_extra_descriptor_filter to return Q-objects

2016-02-11 Thread Django
#26153: Allow get_extra_descriptor_filter to return Q-objects
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"25496f0f7b953b9bca709ab20bc536137f57402d" 25496f0f]:
 {{{
 #!CommitTicketReference repository=""
 revision="25496f0f7b953b9bca709ab20bc536137f57402d"
 [1.9.x] Fixed #26153 -- Reallowed Q-objects in
 ForeignObject.get_extra_descriptor_filter().

 Backport of 353aecbf8c1a8cc6f3985149e2895d49e53dfc1c from master
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.c78f108de2c71bb8475c942beb3c838f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26153: Allow get_extra_descriptor_filter to return Q-objects

2016-02-11 Thread Django
#26153: Allow get_extra_descriptor_filter to return Q-objects
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"353aecbf8c1a8cc6f3985149e2895d49e53dfc1c" 353aecbf]:
 {{{
 #!CommitTicketReference repository=""
 revision="353aecbf8c1a8cc6f3985149e2895d49e53dfc1c"
 Fixed #26153 -- Reallowed Q-objects in
 ForeignObject.get_extra_descriptor_filter().
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.13aaa31fe2ce9e243e7e66e925a313c7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26209: Hide lowercase sensitive setting

2016-02-11 Thread Django
#26209: Hide lowercase sensitive setting
-+-
 Reporter:  francoisfreitag  |Owner:
 |  francoisfreitag
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 I don't see any downside. On the other hand, the convention is to use
 uppercase names for settings so is the only way to encounter this if
 you're defining your own lower case settings?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.7c975cceec5ec009f6f5f5bcaa8897bb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26179: Remove null assignment check for non-nullable foreign key fields

2016-02-11 Thread Django
#26179: Remove null assignment check for non-nullable foreign key fields
-+-
 Reporter:  timgraham|Owner:
 Type:   |  ZachLiuGIS
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.370022099e3f623fc0037f1634813070%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26207: Replace dynamic classes with non-data descriptors for deferred instance loading (was: New implementation for deferred instance loading)

2016-02-11 Thread Django
#26207: Replace dynamic classes with non-data descriptors for deferred instance
loading
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 timgraham):

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


Comment:

 [https://github.com/django/django/pull/6118 PR] and
 [https://groups.google.com/d/msg/django-
 developers/BDAlTyJwQeY/Fh2Qy07cAQAJ django-dev discussion]

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.a648fe92289b9eec9790c403c08c6ef5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26205: migrate and other commands fail with TypeError: 'NoneType' object has no attribute '__getitem__' in schema.py

2016-02-11 Thread Django
#26205: migrate and other commands fail with TypeError: 'NoneType' object has no
attribute '__getitem__' in schema.py
-+-
 Reporter:  mrkiwi-nz|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  schema.py PRAGMA | Triage Stage:
  NonType migrate|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Where do you encounter this old version of SQLite? Django only supports
 the latest point release of each major version of Python, so if this is
 with an older point release, I don't think additional documentation is
 necessary.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f1e4615dff93709cc4cdbb8d06b24f23%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26206: Small in-text example is lost on "Security in Django"

2016-02-11 Thread Django
#26206: Small in-text example is lost on "Security in Django"
---+-
 Reporter:  frostbtn   |Owner:  timgraham
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.9
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-

Comment (by Tim Graham ):

 In [changeset:"9f743e25bd0a18f9b425b42a946e97bf5fed0483" 9f743e2]:
 {{{
 #!CommitTicketReference repository=""
 revision="9f743e25bd0a18f9b425b42a946e97bf5fed0483"
 [1.9.x] Fixed #26206 -- Fixed docs comments causing empty code blocks.

 Backport of f2b45ddd99ff23c0bd103f1dda1e1cb0c8dc6d84 from master
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.e9674b73e26d0c01137fbffd15883b3c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26206: Small in-text example is lost on "Security in Django"

2016-02-11 Thread Django
#26206: Small in-text example is lost on "Security in Django"
---+-
 Reporter:  frostbtn   |Owner:  timgraham
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.9
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"f2b45ddd99ff23c0bd103f1dda1e1cb0c8dc6d84" f2b45dd]:
 {{{
 #!CommitTicketReference repository=""
 revision="f2b45ddd99ff23c0bd103f1dda1e1cb0c8dc6d84"
 Fixed #26206 -- Fixed docs comments causing empty code blocks.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.b49ac9b523438b20472aa57017499c2b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26206: Small in-text example is lost on "Security in Django"

2016-02-11 Thread Django
#26206: Small in-text example is lost on "Security in Django"
---+-
 Reporter:  frostbtn   |Owner:  timgraham
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-
Changes (by timgraham):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => timgraham
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.594bce21a67bb3499ebd0a7756d5f64b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26202: Admin Actions: response_action action_index will never work

2016-02-11 Thread Django
#26202: Admin Actions: response_action action_index will never work
---+--
 Reporter:  wengole|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.91e5c88079dd2cfd0eee65fb85e10a2a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23273: MigrationRecorder does not obey db_router allow_migrate rules

2016-02-11 Thread Django
#23273: MigrationRecorder does not obey db_router allow_migrate rules
+
 Reporter:  froomzy |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 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 marfire):

 Let me amend my last comment: I think that having `migrate` blow up in
 this situation would in fact solve the problem with having an inconsistent
 migrations table, which is the most important thing.

 My question is, since `allow_migrate()` operates at the model level and
 the `migrate` command operates at the app level, wouldn't this make it
 impossible to migrate some models of an app but not others?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.895ed80b8a1a9ae3f1388431e504c1b8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26209: Hide lowercase sensitive setting

2016-02-11 Thread Django
#26209: Hide lowercase sensitive setting
-+-
 Reporter:  francoisfreitag  |Owner:
 |  francoisfreitag
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by francoisfreitag):

 Corresponding PR: https://github.com/django/django/pull/6122

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.c046b3017acf4f73c4e84ae711e783a0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26209: Hide lowercase sensitive setting (was: Hide lowercase sensitive information)

2016-02-11 Thread Django
#26209: Hide lowercase sensitive setting
-+-
 Reporter:  francoisfreitag  |Owner:
 |  francoisfreitag
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by francoisfreitag):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => francoisfreitag
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.dc4b54125f96ab2b444f0a0a2b5a3738%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26209: Hide lowercase sensitive information

2016-02-11 Thread Django
#26209: Hide lowercase sensitive information
-+
 Reporter:  francoisfreitag  |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Utilities|Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+
 Django provides a `cleanse_setting` method[1] that prevents sensitive
 information from being displayed (for example with the `diffsettings`
 command).

 cleanse_settings relies on a case-sensitive regular expression,
 HIDDEN_SETTINGS [2].
 Making `HIDDEN_SETTINGS` case-insensitive would be useful to prevent
 `password` to be shown.

 1:
 
https://github.com/django/django/blob/9332497701f2c69bf0bb6d38ce59a51ca7abe78d/django/views/debug.py#L40-L62
 2:
 
https://github.com/django/django/blob/9332497701f2c69bf0bb6d38ce59a51ca7abe78d/django/views/debug.py#L22

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/058.701a763640126be524a733dcd3b62854%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23273: MigrationRecorder does not obey db_router allow_migrate rules

2016-02-11 Thread Django
#23273: MigrationRecorder does not obey db_router allow_migrate rules
+
 Reporter:  froomzy |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 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 marfire):

 * cc: k@… (added)
 * version:  1.7 => master


Comment:

 I wanted to chime in here to broaden the scope of the bug, as I was
 affected by it recently in a different context.

 The bigger issue is not just that the framework tries to create the
 migrations table where it's not needed, but that it marks as applied
 migrations that in fact were not. That puts the database in an
 inconsistent state, at least as far as migrations are concerned. It's a
 harmless inconsistency for the specific settings file used at that
 specific moment in time, but it lays the seed for big problems down the
 line. For example, if you later decide to change your routing scheme, or
 (as happened in my case) if you have multiple projects with different
 settings using the same app on the same database.

 In terms of a solution, what seems straightforward to my untrained eye is
 for the migration framework to simply not record migrations as applied
 that it didn't apply (and as a corollary, it shouldn't try to create the
 migration table on a database if it doesn't need to record any migrations
 there). The fix suggested above ("to have migrations refuse to run
 entirely and just exit if the migration model is not allowed to be created
 on the target database") doesn't address the broader issue.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f5fcc26ea5d36ddbcfba9cb9c2cf63d1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26200: Integrity constraint violations when ForeignKey field is not included on the ModelForm

2016-02-11 Thread Django
#26200: Integrity constraint violations when ForeignKey field is not included on
the ModelForm
--+--
 Reporter:  goodtune  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Forms |  Version:  1.8
 Severity:  Normal|   Resolution:  duplicate
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by goodtune):

 * status:  new => closed
 * resolution:   => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.37865599cc21d52158e56e8dc38c9aa2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26208: Squashing migrations in which unique=True is added and then removed for Charfield cannot migrate backwards on Postgres

2016-02-11 Thread Django
#26208: Squashing migrations in which unique=True is added and then removed  for
Charfield cannot migrate backwards on Postgres
--+
 Reporter:  linuss|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:|Version:  1.9
  Migrations  |
 Severity:  Normal|   Keywords:  migrations squash charfield unique
 Triage Stage:|  Has patch:  0
  Unreviewed  |
Easy pickings:  0 |  UI/UX:  0
--+
 This bug can be reproduced as follows:
 * Create a model with a CharField with unique=True
 * Create a migration
 * Alter the model so that CharField is no longer unique
 * Create a new migration
 * Squash the two migrations
 * Migrate forwards, and then backwards

 Error output:
 {{{
 psycopg2.ProgrammingError: relation
 "survey_respondent_email_b0f1dc87_like" already exists


 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/core/management/__init__.py", line 353, in
 execute_from_command_line
 utility.execute()
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/core/management/__init__.py", line 345, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/core/management/base.py", line 348, in run_from_argv
 self.execute(*args, **cmd_options)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/core/management/base.py", line 399, in execute
 output = self.handle(*args, **options)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/core/management/commands/migrate.py", line 200, in
 handle
 executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/db/migrations/executor.py", line 96, in migrate
 self._migrate_all_backwards(plan, full_plan, fake=fake)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/db/migrations/executor.py", line 163, in
 _migrate_all_backwards
 self.unapply_migration(states[migration], migration, fake=fake)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/db/migrations/executor.py", line 218, in
 unapply_migration
 state = migration.unapply(state, schema_editor)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/db/migrations/migration.py", line 172, in unapply
 operation.database_backwards(self.app_label, schema_editor,
 from_state, to_state)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/db/migrations/operations/fields.py", line 206, in
 database_backwards
 self.database_forwards(app_label, schema_editor, from_state, to_state)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/db/migrations/operations/fields.py", line 201, in
 database_forwards
 schema_editor.alter_field(from_model, from_field, to_field)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/db/backends/base/schema.py", line 482, in
 alter_field
 old_db_params, new_db_params, strict)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/db/backends/postgresql/schema.py", line 116, in
 _alter_field
 self.execute(like_index_statement)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/db/backends/base/schema.py", line 110, in execute
 cursor.execute(sql, params)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/db/backends/utils.py", line 79, in execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
   File
 "/var/lib/jenkins/shiningpanda/jobs/914dc536/virtualenvs/d41d8cd9/lib/python3.4
 /site-packages/django/db/utils.py", line 95, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File
 

[Django] #26207: New implementation for deferred instance loading

2016-02-11 Thread Django
#26207: New implementation for deferred instance loading
-+-
   Reporter:  akaariai   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Instead of creating subclasses of the real model with descriptors for the
 deferred fields, always add non-data descriptors for all concrete fields.
 Gone is dynamic class creation for deferred loading!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.3a78173203279652eb5bd2f9fa10dd3f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26202: Admin Actions: response_action action_index will never work

2016-02-11 Thread Django
#26202: Admin Actions: response_action action_index will never work
---+--
 Reporter:  wengole|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.9
 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 wengole):

 This is invalid. Upon further investigation, this is how QueryDict is
 supposed to work. The update() call appends the value at action_index to
 the end of the list. The get() call later in the form's clean() process
 returns the last element in the list.

 There is some weird issue where if I'm using PyCharm's debugger, and break
 before form.is_valid() is called, it will always return False even through
 stepping through the code shows that the POST data is processed correctly
 and should validate the form.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.983d03919b9af33a25d0d0b37e6af0fd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.