date:20150810

Re: [Django] #25259: Add Django version in a comment (hint) to auto-generated migration files

2015-08-10 Thread Django

#25259: Add Django version in a comment (hint) to auto-generated migration files
-+
 Reporter:  tysonclugg   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migrations   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by MarkusH):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/068.f5a5171d0938ec1f97bd85a486e10af1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25259: Add Django version in a comment (hint) to auto-generated migration files

2015-08-10 Thread Django

#25259: Add Django version in a comment (hint) to auto-generated migration files
-+
 Reporter:  tysonclugg   |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Migrations   |Version:  master
 Severity:  Normal   |   Keywords:  migrations
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+
 Add a comment such as:
 {{{#!python
 # Generated by Django 1.8.3 on 2015-08-11 16:50:15
 }}}

 This will help identify possible future compatibility issues with
 migrations.

--
Ticket URL: 
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/053.0412ab3bac1580819592c26f2eb139a3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25239: Running makemigrations yields file number 0001 if the app's latest migration has a number-only filename

2015-08-10 Thread Django

#25239: Running makemigrations yields file number 0001 if the app's latest
migration has a number-only filename
-+-
 Reporter:  zettabyte|Owner:
 |  caioariede
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  migrations   | Triage Stage:  Accepted
  makemigrations |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by caioariede):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/5128

--
Ticket URL: 
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.571137693df65cce132e5ffced715d4d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25258: ExpressionWrapper documentation should be expanded

2015-08-10 Thread Django

#25258: ExpressionWrapper documentation should be expanded
--+
 Reporter:  tarkatronic   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  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 tarkatronic):

 I would actually be a fan of the first option as, if I'm not mistaken,
 that would produce the expected behavior from my original snippet. I can
 see how a Case/When could be made to work in this case, but it doesn't
 seem as natural. Of course, this is also the first time I'm even hearing
 of those being available in Django.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.0559ad403a2f943c11397e18813b1156%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25258: ExpressionWrapper documentation should be expanded

2015-08-10 Thread Django

Comment (by jarshwah):

`Q()` objects aren't actually expressions, but they are made from similar
base types, and support parts of the expression API by virtue of being
required by `Case Expressions`
https://docs.djangoproject.com/en/1.8/ref/models/conditional-expressions/.

I've seen quite a few cases of people using `Q()` objects as expressions
lately, when they really should be using Conditional Expressions instead.

So, I agree that something here needs to be fixed or documented. But
`ExpressionWrapper` really is only meant to be used to wrap existing
expressions, so I'm not too keen on documenting ExpressionWrapper further
at this point.

I guess we could define the output_field of Q() objects as always
returning a BooleanField but, again, they aren't exactly Expressions
themselves although they are close.

I think the better options here are:

1) Make Q() objects actual expressions (by implementing the full
expression API on them). Not sure if Q() expressions will always work as
annotations though, conditional expressions had some extra work to do to
be compliant cross database.

2) Highlight that Conditional Expressions should be used in the
documentation and error messages where Q() objects are mentioned. Erroring
early on direct Q() usage in annotations and guiding the user to Case/When
is what I imagine here.

I'm open to further suggestions.

--
Ticket URL:
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.99fad353f71c07a79a8edb0632420398%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24987: django.test.client.Client.login() rejects user with is_active=False

2015-08-10 Thread Django

#24987: django.test.client.Client.login() rejects user with is_active=False
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 #25232 might allow removing the check in the test client `login()` method.

--
Ticket URL: 
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.e00ab474ee581949aff62c8c5ee05e07%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25232: Make the ModelBackend authentication backend reject inactive users

2015-08-10 Thread Django

#25232: Make the ModelBackend authentication backend reject inactive users
--+--
 Reporter:  OleLaursen|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 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):

 * Attachment "25232.diff" 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 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/068.2445e8114e88b675899178b4c70bc134%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25232: Make the ModelBackend authentication backend reject inactive users (was: Add a setting to make the ModelBackend reject inactive users)

2015-08-10 Thread Django

#25232: Make the ModelBackend authentication backend reject inactive users
--+--
 Reporter:  OleLaursen|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 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):

 * version:  1.8 => master


Comment:

 It might also be possible to fix #24987 and remove the `user.is_active`
 check in the test client `login()` method. A draft patch is attached, but
 some test failures remain.

 For backwards compatibility, should we provide an authentication backend
 that allows inactive users:
 {{{
 class AllowInactiveUsersModelBackend(ModelBackend):
 allow_inactive_users = True
 }}}
 (incorporating that flag into the patch).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/068.bf7a248ebafef36cfab4934862ce400b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23763: Python 3.5 compatibility

2015-08-10 Thread Django

#23763: Python 3.5 compatibility
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  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 timgraham):

 I don't believe it's a known issue. It doesn't seem related to Python 3.5
 compatibility, so please open a new ticket with more specifics, 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/067.b3aa73783623657e65124001fcbd5ae2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #13871: contrib.admin:list_editable - ForeignKey performance is O(m*n)

2015-08-10 Thread Django

#13871: contrib.admin:list_editable - ForeignKey performance is O(m*n)
-+-
 Reporter:  chadc|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  list_editable,   | Triage Stage:  Accepted
  admin, ForeignKey, admin   |
  efficiency |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by kissgyorgy):

 * version:  1.2 => 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/063.b857aaa5eeb1041f859c1af88b687ff8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #13871: contrib.admin:list_editable - ForeignKey performance is O(m*n)

2015-08-10 Thread Django

#13871: contrib.admin:list_editable - ForeignKey performance is O(m*n)
-+-
 Reporter:  chadc|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  list_editable,   | Triage Stage:  Accepted
  admin, ForeignKey, admin   |
  efficiency |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by kissgyorgy):

 * cc: kissgyorgy@… (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 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.a7bc8e9821a898d1b90d1a4be6601559%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23763: Python 3.5 compatibility

2015-08-10 Thread Django

Comment (by warsaw):

Any thoughts on the GEOSGeometry import error on Python 3 only? I think
I've applied all the relevant patches here for Ubuntu's build of 1.7.9 for
Python 2.7, 3.4, and 3.5, and this is the last failure I can't yet
eliminate. Well, I can if I depend on libgeos-dev which gives you the
right library, but I don't want to add that dependency because of cross-
pocket issues (django-python is in main, but libgeos-dev is in universe,
and that would require extra bureaucracy to change).

I've confirmed that HAS_SPACIAL_DB is False in both Python 2 and 3, and
django.contrib.gis.tests doesn't get added to discovery_paths (in
runtests.py), but yet those tests are still discovered.

Is there some patch not yet attached to this issue, or some other ticket
or commit I should be looking at?

--
Ticket URL:
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.c9c8bc07fee29976ca693f15a2c975e8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25258: ExpressionWrapper documentation should be expanded

2015-08-10 Thread Django

#25258: ExpressionWrapper documentation should be expanded
--+
 Reporter:  tarkatronic   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  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
--+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Bug => Cleanup/optimization
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 If you could provide a patch based on what you have learned that would be
 great.

--
Ticket URL: 
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.a6da86129f89f355a89f38078f3c7943%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25257: Changing CharField to GenericIPAddressField with PostgreSQL should use "using field::inet"

2015-08-10 Thread Django

#25257: Changing CharField to GenericIPAddressField with PostgreSQL should use
"using field::inet"
-+-
 Reporter:  Naddiseo |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  duplicate
 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 timgraham):

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


Comment:

 Duplicate of #25002. Backport was discussed briefly there and declined.

--
Ticket URL: 
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.6ede6a9e951fb8bff5b100ac58be9b67%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25232: Add a setting to make the ModelBackend reject inactive users

2015-08-10 Thread Django

#25232: Add a setting to make the ModelBackend reject inactive users
--+--
 Reporter:  OleLaursen|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.8
 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 carljm):

 I agree with Aymeric that it's just a bug if the backend behavior doesn't
 match the login form behavior. Both are easily overrideable.

--
Ticket URL: 
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/068.e0b44675190fd715a4cc94c3dc248076%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25257: Changing CharField to GenericIPAddressField with PostgreSQL should use "using field::inet"

2015-08-10 Thread Django

#25257: Changing CharField to GenericIPAddressField with PostgreSQL should use
"using field::inet"
-+
 Reporter:  Naddiseo |Owner:  nobody
 Type:  New feature  |   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 Naddiseo):

 @charettes, looks like it works on master. Any chance of a backport?

--
Ticket URL: 
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.37626dc89388934a4bb8d6ee45a08f1c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25251: TransactionTestCase and --keepdb

2015-08-10 Thread Django

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

Comment:

A `TransactionTestCase` resets the database after the test runs by
truncating all tables. For this reason,
[https://docs.djangoproject.com/en/1.8/topics/testing/overview/#rollback-
emulation the docs say], "Any initial data loaded in migrations will only
be available in `TestCase` tests and not in `TransactionTestCase` tests."
I think that technically the data is available in the first
`TransactionTestCase` (since truncation hasn't happened yet), but not any
others. Perhaps this should be fixed or the docs clarified.

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

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To 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.6e08862b98cca39c2e361638a34b9cbb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25258: ExpressionWrapper documentation should be expanded

2015-08-10 Thread Django

#25258: ExpressionWrapper documentation should be expanded
---+
 Reporter:  tarkatronic|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Currently, ExpressionWrapper has very limited documentation and is only
 mentioned for use specifically
 [[https://docs.djangoproject.com/en/1.8/ref/models/expressions/#using-f
 -with-annotations|in conjunction with F()]].

 I ran into a case, using what seems a fairly simple annotation on the
 surface, where I needed to use an ExpressionWrapper, but this was not at
 all clear from either the error message, any bug reports, or the
 documentation.

 The following:
 {{{
 #!python
 Category.objects.annotate(
 has_children=(
 Q(children__merchants__isnull=False) |
 Q(children__children__merchants__isnull=False)
 )
 )
 }}}

 was producing the error:

 {{{
 AttributeError: 'WhereNode' object has no attribute 'output_field'
 }}}

 What I ultimately needed was:
 {{{
 #!python
 Category.objects.annotate(
 has_children=ExpressionWrapper(
 Q(children__merchants__isnull=False) |
 Q(children__children__merchants__isnull=False),
 output_field=BooleanField()
 )
 )
 }}}

 However, I only stumbled upon this solution completely by accident and on
 a hunch.

 I think that the documentation for ExpressionWrapper() should be expanded
 to cover a more broad use case, and perhaps a more clear error message
 could be provided in cases such as the one I encountered.

--
Ticket URL: 
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.cc9080158432b487d88372e47a7b4a00%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25232: Add a setting to make the ModelBackend reject inactive users

2015-08-10 Thread Django

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

Comment:

The manual workaround is to change a user's password, assuming
`SessionAuthenticationMiddleware` is installed... That said I'm not
comfortable with suggesting workarounds. The current situation could
easily be described as a security issue.

I don't think adding a setting is a solution because using the default
value will leave sites vulnerable. I think we should fix the bug, document
the backwards-incompatibility and provide a way to restore the previous
behavior.

I'm going to reopen the bug in the hope to gather more feedback. If no one
thinks fixing is a good idea, we can close it 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 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/068.b01e6b97540919081b5dd705f1f49355%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25232: Add a setting to make the ModelBackend reject inactive users (was: Deactivating users with is_active)

2015-08-10 Thread Django

#25232: Add a setting to make the ModelBackend reject inactive users
--+--
 Reporter:  OleLaursen|Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  1.8
 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 timgraham):

 * status:  new => closed
 * type:  Uncategorized => New feature
 * resolution:   => wontfix


Comment:

 It seems to me this could be accomplished without much difficulty by
 overriding the `ModelBackend`. Something like (untested):
 {{{#!python
 class RejectInactiveUsersBackend(ModelBackend):
 def get_user(self, user_id):
 user = super(RejectInactiveUsersBackend, self).get_user(user_id)
 if user and not user.is_active:
 return None
 return user
 }}}
 It's probably better to recommend that route instead of adding a setting.

--
Ticket URL: 
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/068.3b145f7de1a6e41083446dacef75ae28%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25257: Changing CharField to GenericIPAddressField with PostgreSQL should use "using field::inet"

2015-08-10 Thread Django

#25257: Changing CharField to GenericIPAddressField with PostgreSQL should use
"using field::inet"
-+
 Reporter:  Naddiseo |Owner:  nobody
 Type:  New feature  |   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 charettes):

 This looks related to #25002 (73040e584a9ccc770593a3885f5fe40fda142e0d).
 Can you confirm this is working using the master branch?

--
Ticket URL: 
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.b3ca2f2cff34fd0e4ea5dfe0ff7cc31f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25223: Allow default language to be one unsupported by django if the local project has the required translation catalog

2015-08-10 Thread Django

#25223: Allow default language to be one unsupported by django if the local 
project
has the required translation catalog
--+
 Reporter:  svleeuwen |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  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
--+
Changes (by timgraham):

 * 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/067.74ff332e0126bdb97861ed57eb5a1710%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25234: Add an option to disable System Checks

2015-08-10 Thread Django

#25234: Add an option to disable System Checks
-+-
 Reporter:  marcinn  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  1.8
  commands)  |
 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 timgraham):

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


Comment:

 I'm not yet convinced there is a strong demand for disabling all checks
 instead of disabling the ones that you don't find useful or give false-
 positives on your project. Will happily reopen if the mailing list
 discussion decides otherwise.

--
Ticket URL: 
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.26b1d4388e6f09fa1f993dca265dbd2b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25228: Performance degradation of template rendering

2015-08-10 Thread Django

#25228: Performance degradation of template rendering
-+--
 Reporter:  yml  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 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):

 If you could bisect to find the commit where the performance change
 significantly, that will help assess what (if anything) can be 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/061.4be61fac891aa0bf6fd1324d7f1c4ac3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25218: python_2_unicode_compatible causes infinite recursion when super().str() is called

2015-08-10 Thread Django

#25218: python_2_unicode_compatible causes infinite recursion when
super().__str__() is called
---+--
 Reporter:  jscn   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Utilities  |  Version:  1.8
 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 timgraham):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/062.dfaeec70b485108489eed68dc64a2546%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25227: Promote modifying form.instance directly instead of using ModelForm.save(commit=False) (was: Remove need for `ModelForm.save(commit=False)`)

2015-08-10 Thread Django

#25227: Promote modifying form.instance directly instead of using
ModelForm.save(commit=False)
--+
 Reporter:  candeira  |Owner:  candeira
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  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 timgraham):

 * has_patch:  1 => 0
 * stage:  Unreviewed => Accepted
 * component:  Forms => Documentation


Comment:

 Tentatively accepting as a documentation issue based on latest discussion
 [https://groups.google.com/d/topic/django-
 developers/yEBrVSntSkA/discussion on django-developers].

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.84bcc34ab8fe5d4b8e915d435d067013%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25255: MigrationExecutor.check_replacements() doesn't take care of unapplied migrations

2015-08-10 Thread Django

#25255: MigrationExecutor.check_replacements() doesn't take care of unapplied
migrations
+
 Reporter:  MarkusH |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  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
+
Changes (by timgraham):

 * 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/065.a1d853ed69709251a02f6ec07013fa6d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25214: Behavior of _meta.auto_created = True in m2m through model is not expected.

2015-08-10 Thread Django

#25214: Behavior of  _meta.auto_created = True in m2m through model is not
expected.
+--
 Reporter:  Cinkz   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:  needsinfo
 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:   => needsinfo


--
Ticket URL: 
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.761451861a211a030e9cd499b178fb93%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25252: Add a friendly error message when using Queryset.select_related() after values() (was: Queryset with 'values' and 'select_related' won't work)

2015-08-10 Thread Django

#25252: Add a friendly error message when using Queryset.select_related() after
values()
-+-
 Reporter:  2roy999  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset values  | Triage Stage:  Accepted
  select_related |
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
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 We could add a friendly error message for that case. There's no purpose to
 using `select_related()` after `values()` because `values()` already
 selects only the values it needs.

--
Ticket URL: 
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.8c5070e36405b8a916a16b6194397a68%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25150: Iterable objects are converted to lists during SQL handling

2015-08-10 Thread Django

#25150: Iterable objects are converted to lists during SQL handling
-+-
 Reporter:  ekoyle   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 This is [https://github.com/jimfunk/django-postgresql-
 netfields/commit/4866192da3c84c67aa174b28fb511b72340c2726 fixed in django-
 postgresql-netfields].

--
Ticket URL: 
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.a81cab8c5697670f86305673322ac27f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11964: Add the ability to use database-level CHECK CONSTRAINTS

2015-08-10 Thread Django

#11964: Add the ability to use database-level CHECK CONSTRAINTS
-+-
 Reporter:  schinckel|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  check contsraint | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by gam_phon):

 * cc: gam_phon (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 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.4ba5a907b14b92e804af9ff230dcb2bd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25257: Changing CharField to GenericIPAddressField with PostgreSQL should use "using field::inet" (was: Changing CharField to GenericIpAddress post postgresql should use "using field::in

2015-08-10 Thread Django

#25257: Changing CharField to GenericIPAddressField with PostgreSQL should use
"using field::inet"
-+
 Reporter:  Naddiseo |Owner:  nobody
 Type:  New feature  |   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 timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  1.8 => master
 * needs_docs:   => 0
 * type:  Uncategorized => New feature
 * stage:  Unreviewed => Accepted


Comment:

 If not too difficult to implement, that would be useful. If not, we should
 document that using RawSQL is required for such cases.

--
Ticket URL: 
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.48eede5ce09e62b724196cb8bcbc917e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25257: Changing CharField to GenericIpAddress post postgresql should use "using field::inet"

2015-08-10 Thread Django

#25257: Changing CharField to GenericIpAddress post postgresql should use "using
field::inet"
---+
 Reporter:  Naddiseo   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Migrations |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The sql issued to postgresql when converting a CharField to a
 GenericIpAddress should be along the line of
 {{{#!sql
 ALTER TABLE table ALTER COLUMN ip_field TYPE inet USING ip_field::inet;
 }}}

 Instead I get an error:
 django.db.utils.ProgrammingError: column "ip" cannot be cast automatically
 to type inet
 HINT:  Specify a USING expression to perform the conversion.

--
Ticket URL: 
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.47e23b40e7fad2a08a42ed9eaa1a753d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25160: Move unsaved model instance assignment check to model.save()

2015-08-10 Thread Django

#25160: Move unsaved model instance assignment check to model.save()
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 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:"e4b813c0e723e774c5c7386a29f10bc807a47e47" e4b813c]:
 {{{
 #!CommitTicketReference repository=""
 revision="e4b813c0e723e774c5c7386a29f10bc807a47e47"
 [1.8.x] Fixed #25160 -- Moved unsaved model instance data loss check to
 Model.save()

 This mostly reverts 5643a3b51be338196d0b292d5626ad43648448d3 and
 81e1a35c364e5353d2bf99368ad30a4184fbb653.

 Thanks Carl Meyer for review.

 Backport of 5980b05c1fad69eef907e0076aa2dc837edab529 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/067.8a8f3f535a0799a1050b02d50cb15f15%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25254: Allow control over json.dumps keyword arguments in JsonResponse

2015-08-10 Thread Django

#25254: Allow control over json.dumps keyword arguments in JsonResponse
-+-
 Reporter:  jaap3|Owner:  darkryder
 Type:  New feature  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  json dumps indent| Triage Stage:  Accepted
  separators jsonresponse|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by darkryder):

 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/5127

--
Ticket URL: 
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.b775db6ce51001cd4a5af37466100769%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25254: Allow control over json.dumps keyword arguments in JsonResponse

2015-08-10 Thread Django

#25254: Allow control over json.dumps keyword arguments in JsonResponse
-+-
 Reporter:  jaap3|Owner:  darkryder
 Type:  New feature  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  json dumps indent| Triage Stage:  Accepted
  separators jsonresponse|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by darkryder):

 * owner:  nobody => darkryder
 * status:  new => assigned


Comment:

 Going to add parameter which would take in dictionary and pass `kwargs` as
 suggested by timgraham.

--
Ticket URL: 
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.d8bf7f7a2219975ca0aa399af93f37c0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25256: Django 1.4.18 broke USE_ETAGS with static views

2015-08-10 Thread Django

#25256: Django 1.4.18 broke USE_ETAGS with static views
---+--
 Reporter:  jsonn  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.4
 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:

 Care to offer a patch?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.1968fb381571b6da88ed100fda74f75c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25254: Allow control over json.dumps keyword arguments in JsonResponse

2015-08-10 Thread Django

#25254: Allow control over json.dumps keyword arguments in JsonResponse
-+-
 Reporter:  jaap3|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  json dumps indent| Triage Stage:  Accepted
  separators jsonresponse|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Maybe it would make sense to add a parameter: `json_dumps_options=None`
 which could be a dictionary of options.

--
Ticket URL: 
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.ab861208de816d57fbb6126e40a325af%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25256: Django 1.4.18 broke USE_ETAGS with static views

2015-08-10 Thread Django

#25256: Django 1.4.18 broke USE_ETAGS with static views
---+
 Reporter:  jsonn  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The streaming fix in Django 1.4.18 breaks USE_ETAGS, similar to how the
 gzip middleware got broken. It would be nice to at least document this
 either in the release notes for 1.4.18 or 1.4.22.

--
Ticket URL: 
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/048.20e3df505847d8a53daf8dcc612adb90%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25160: Move unsaved model instance assignment check to model.save()

2015-08-10 Thread Django

#25160: Move unsaved model instance assignment check to model.save()
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 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:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"5980b05c1fad69eef907e0076aa2dc837edab529" 5980b05c]:
 {{{
 #!CommitTicketReference repository=""
 revision="5980b05c1fad69eef907e0076aa2dc837edab529"
 Fixed #25160 -- Moved unsaved model instance data loss check to
 Model.save()

 This mostly reverts 5643a3b51be338196d0b292d5626ad43648448d3 and
 81e1a35c364e5353d2bf99368ad30a4184fbb653.

 Thanks Carl Meyer for review.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.6aa6f5fdd812c9ab17a35c0c38b4eadb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25228: Performance degradation of template rendering

2015-08-10 Thread Django

#25228: Performance degradation of template rendering
-+--
 Reporter:  yml  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 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 yml):

 I did another run with all the releases from 1.8 series and django-tip. I
 confirm that django-tip improves the situation but it is still slower
 than the releases before `1.8.3` :

 || ||= standalone   =||= extends
 =||= include  =|| include & extends =||
 || 1.8.0   ||0.520450115204  ||0.841553926468   ||
 4.12727284431   ||7.55168485641||
 || 1.8.1   ||0.549235105515  ||0.868353843689
 ||4.21892404556||7.14691209793||
 || 1.8.2   || 0.591598987579 ||0.840734004974
 ||4.22193288803||6.90138411522||
 || 1.8.3   || 1.48196005821   ||1.79811000824 ||
 5.08307695389   || 8.11770391464   ||
 || tip 2015-08-10  || 0.620449066162 ||0.92530298233
 ||4.18256998062|| 7.9185230732   ||

 This was done using the following command in this [https://github.com/yml
 /django-perfo-regression repo]:

 `tox -e
 py27-django-1.8.0,py27-django-1.8.1,py27-django-1.8.2,py27-django-1.8.3,py27
 -django-tip`

--
Ticket URL: 
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/061.c755af0cc46de6556b72f7fba7b0851d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25254: Allow control over json.dumps keyword arguments in JsonResponse

2015-08-10 Thread Django

#25254: Allow control over json.dumps keyword arguments in JsonResponse
-+-
 Reporter:  jaap3|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  json dumps indent| Triage Stage:  Accepted
  separators jsonresponse|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * 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/063.7e8ca56b7c800871f5eecd94d5a4c73a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24743: Django 1.8.1 migrations are actually slower than 1.8?

2015-08-10 Thread Django

#24743: Django 1.8.1 migrations are actually slower than 1.8?
--+
 Reporter:  pzrq  |Owner:  MarkusH
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  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 MarkusH):

 I rebased the current implementation onto the recent master in a new PR:
 https://github.com/django/django/pull/5125

--
Ticket URL: 
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/062.d00acfeb493229f4fa7f8ce4ab665355%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #12856: Decide on public API/documentation for form.BoundField attributes

2015-08-10 Thread Django

#12856: Decide on public API/documentation for form.BoundField attributes
-+-
 Reporter:  mnbayazit|Owner:  MoritzS
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  boundfield required  | Triage Stage:  Accepted
  is_hidden auto_id  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by MoritzS):

 * needs_docs:  1 => 0
 * has_patch:  0 => 1


Comment:

 Added PR: https://github.com/django/django/pull/5123

--
Ticket URL: 
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.decfe0433f01a9fb359b5cf15941ccfe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24743: Django 1.8.1 migrations are actually slower than 1.8?

2015-08-10 Thread Django

#24743: Django 1.8.1 migrations are actually slower than 1.8?
--+
 Reporter:  pzrq  |Owner:  MarkusH
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  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 MarkusH):

 Thank you etanol! Here is the output of the first rows sorted by
 "cumtime". This clearly shows (from my perspective) a high expense in the
 model's meta class: `django/db/models/base.py:72(__new__)`

 {{{

  1538924506 function calls (1535110811 primitive calls) in
 1483.255 seconds

Ordered by: cumulative time

ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 10.0000.000 1483.272 1483.272
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/core/management/base.py:369(run_from_argv)
  16/10.0010.000 1483.270 1483.270
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/core/management/base.py:404(execute)
 10.0080.008 1482.956 1482.956
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/core/management/commands/migrate.py:55(handle)
 10.0030.003 1473.721 1473.721
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/migrations/executor.py:65(migrate)
  18090.5010.000 1471.6180.813
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/migrations/state.py:91(reload_model)
   1480.0080.000 1468.4309.922
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/migrations/migration.py:72(mutate_state)
  15360.6100.000 1441.0010.938
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/migrations/state.py:252(render_multiple)
2392628.4760.000 1440.3900.006
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/migrations/state.py:520(render)
  13520.0580.000 1124.9410.832
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/migrations/operations/fields.py:43(state_forwards)
 300486/239262   13.2540.000  834.4750.003
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/models/base.py:72(__new__)
   4083939   21.9460.000  595.1300.000
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/migrations/state.py:488(construct_fields)
3004861.4860.000  498.4340.002
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/migrations/state.py:285(register_model)
302024   29.8340.000  496.3820.002
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/apps/registry.py:334(clear_cache)
  40673088  270.2230.000  388.2860.000
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/models/options.py:711(_expire_cache)
 5237503/48089357.4850.000  320.2860.000
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/models/base.py:321(add_to_class)
7349462.3350.000  263.0460.000
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/utils/lru_cache.py:94(wrapper)
522243   40.9210.000  255.0000.000
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/apps/registry.py:153(get_models)
430612   81.3650.000  240.7800.001
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/models/fields/related.py:309(swappable_setting)
3693881.6610.000  232.5810.001
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/models/fields/related.py:1867(deconstruct)
3693882.6920.000  230.3880.001
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/models/fields/related.py:1551(deconstruct)
 105539832   90.4300.000  200.6470.000
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/apps/config.py:164(get_models)
   2330.0120.000  197.5410.848
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/migrations/operations/fields.py:172(state_forwards)
   3844735  113.1340.000  176.8510.000
 /home/isaac/virtualenvs/bookcore/local/lib/python2.7/site-
 packages/django/db/models/fields/__init_

Re: [Django] #25227: Remove need for `ModelForm.save(commit=False)` (was: Add utility method `get_updated_model()` to `ModelForm`)

2015-08-10 Thread Django

#25227: Remove need for `ModelForm.save(commit=False)`
-+-
 Reporter:  candeira |Owner:  candeira
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by candeira:

Old description:

> Add utility method get_updated_model() to ModelForm
>
> Additionally, add utility method get_updated_models() to FormSet
>
> Rationale:
>
> While doing the djangogirls tutorial, I noticed that
> ModelForm.save(commit=False) is given to newcomers as a reasonable way to
> acquire a form's populated model. This is an antipattern for several
> reasons:
>
>   - It's counterintuitive. To a newcomer, it's the same as
> ``save(save=no)``.
>   - It's a leaky abstraction. Understanding it requires understanding
> that the save method does two things: a) prepare the model, and b) save
> it to the database.
>   - It doesn't name its effect or return well.
>
> All these problems are addressed in the current patch. Changes:
>
>  - Implement ModelForm.get_updated_model()
>  - Implement FormSet.get_updated_models()
>  - Refactor ModelForm.save() and FormSet.save() to allow the above.
>  - Both the tests and contrib.auth have been modified: any call to
> save(commit=False) for the purpose of obtaining a populated model has
> been replaced by get_updated_model(). Tests still pass, I'm confident
> it's a successful refactor.
> - New tests have been added for the new methods in different contexts
> (from a ModelForm, from a FormSet, etc).
>  - documentation has also been modified to showcase the new methods.
>
> Notes:
>
> Uses of ModelForm.save(commit=False) in the codebase have been left alone
> wherever it was used for its side effects and not for its return value.
>
> The Djangogirls tutorial has a PR that depends on the changes in the
> present one:
>
> https://github.com/DjangoGirls/tutorial/pull/450

New description:

 While doing the djangogirls tutorial, I noticed that
 ModelForm.save(commit=False) is given to newcomers as a reasonable way to
 acquire a form's populated model. This is an antipattern for several
 reasons:

   - It's counterintuitive. To a newcomer, it's the same as
 ``save(save=no)``.
   - It's a leaky abstraction. Understanding it requires understanding that
 the `save()` method does two things: a) return the model, and b) save it
 to the database.
   - It doesn't name its effect or return well.

 The first two issues are addressed in the current patch. About the third,
 the mailing list discussion convinced me to avoid the
 `.get_updated_model()` name. Instead, `apply()` was used.

 Changes:

  - Implement `ModelForm.apply()` as alternative to `.save(commit=False)`
  - Implement `FormSet.apply()` as alternative to `.save(commit=False)`
  - Refactor `ModelForm.save()` and `FormSet.save()` to allow the above.
  - New tests have been added for the new methods in different contexts
 (from a ModelForm, from a FormSet, etc).
  - documentation has also been modified to showcase the new methods.

 Notes:

 Uses of either `.save(commit=False)` in the codebase have been left alone
 wherever it was used for its side effects (the return value was not used).

 The Djangogirls tutorial has a PR that depends on the changes in the
 present one:

 https://github.com/DjangoGirls/tutorial/pull/450

--

--
Ticket URL: 
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.e08612811225ea96894342ac55191c6c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25255: MigrationExecutor.check_replacements() doesn't take care of unapplied migrations

2015-08-10 Thread Django

#25255: MigrationExecutor.check_replacements() doesn't take care of unapplied
migrations
--+
   Reporter:  MarkusH |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  1.8
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 When unapplying a squashed migration an the replaced migration files are
 still around, the `MigrationExecutor` schould also mark those as
 unapplied.

--
Ticket URL: 
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/050.210509799f1d0097579483df9888f92b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25245: Incorrect query arising from using NOT-clauses & multiple relation references affected node position in Q

2015-08-10 Thread Django

#25245: Incorrect query arising from using NOT-clauses & multiple relation
references affected node position in Q
-+-
 Reporter:  ris  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  exclude exclude  | Triage Stage:
  manytomany Q order |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ris):

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


Old description:

> This may (or may not) be related to the bug being fixed in PR4385
> (https://github.com/django/django/pull/4385) and/or #14645, however even
> if it is I think this displays an interesting facet to this.
>
> The order Q clauses are specified in the Q expression will affect the
> (in)correctness of the generated query.
>
> Using django 1.8.3 example models.py:
>
> {{{
> from django.db import models
>
> class ModelA ( models.Model ):
> pass
>
> class ModelB ( models.Model ):
> a = models.ForeignKey ( ModelA )
>
> field_f = models.IntegerField ()
> field_g = models.IntegerField ()
> }}}
>
> Specify the query one way around:
>
> {{{
> >>> x = ModelA.objects.filter ( ( Q ( modelb__field_f = 3 ) & Q (
> modelb__field_g__gte = 50 ) ) | ~Q ( modelb__field_f = 3 ) ).distinct ()
> >>> str ( x.query )
> 'SELECT DISTINCT "dummy_modela"."id" FROM "dummy_modela" LEFT OUTER JOIN
> "dummy_modelb" ON ( "dummy_modela"."id" = "dummy_modelb"."a_id" ) WHERE
> (("dummy_modelb"."field_f" = 3 AND "dummy_modelb"."field_g" >= 50) OR NOT
> ("dummy_modela"."id" IN (SELECT U1."a_id" AS Col1 FROM "dummy_modelb" U1
> WHERE (U1."field_f" = 3 AND U1."id" = ("dummy_modelb"."id")'
> }}}
>
> Generates one piece of SQL. Specify it in a different order:
>
> {{{
> >>> y = ModelA.objects.filter ( (~Q ( modelb__field_f = 3 )) | ( Q (
> modelb__field_f = 3 ) & Q ( modelb__field_g__gte = 50 ) ) ).distinct ()
> >>> str ( y.query )
> 'SELECT DISTINCT "dummy_modela"."id" FROM "dummy_modela" LEFT OUTER JOIN
> "dummy_modelb" ON ( "dummy_modela"."id" = "dummy_modelb"."a_id" ) WHERE
> (NOT ("dummy_modela"."id" IN (SELECT U1."a_id" AS Col1 FROM
> "dummy_modelb" U1 WHERE U1."field_f" = 3)) OR ("dummy_modelb"."field_f" =
> 3 AND "dummy_modelb"."field_g" >= 50))'
> }}}
>
> Generates quite different SQL, which returns different results.
>
> Would like to be sure PR4385 fixes this case.

New description:

 This may (or may not) be related to the bug being fixed in PR4385
 (https://github.com/django/django/pull/4385) and/or #14645, however even
 if it is I think this displays an interesting facet to this.

 The order Q clauses are specified in the Q expression will affect the
 (in)correctness of the generated query.

 Using django 1.8.3 example models.py:

 {{{
 from django.db import models

 class ModelA ( models.Model ):
 pass

 class ModelB ( models.Model ):
 a = models.ForeignKey ( ModelA )

 field_f = models.IntegerField ()
 field_g = models.IntegerField ()
 }}}

 Specify the query one way around:

 {{{
 >>> x = ModelA.objects.filter ( ( Q ( modelb__field_f = 3 ) & Q (
 modelb__field_g__gte = 50 ) ) | ~Q ( modelb__field_f = 3 ) ).distinct ()
 >>> str ( x.query )
 'SELECT DISTINCT "dummy_modela"."id" FROM "dummy_modela" LEFT OUTER JOIN
 "dummy_modelb" ON ( "dummy_modela"."id" = "dummy_modelb"."a_id" ) WHERE
 (("dummy_modelb"."field_f" = 3 AND "dummy_modelb"."field_g" >= 50) OR NOT
 ("dummy_modela"."id" IN (SELECT U1."a_id" AS Col1 FROM "dummy_modelb" U1
 WHERE (U1."field_f" = 3 AND U1."id" = ("dummy_modelb"."id")'
 }}}

 Generates one piece of SQL. Specify it in a different order:

 {{{
 >>> y = ModelA.objects.filter ( (~Q ( modelb__field_f = 3 )) | ( Q (
 modelb__field_f = 3 ) & Q ( modelb__field_g__gte = 50 ) ) ).distinct ()
 >>> str ( y.query )
 'SELECT DISTINCT "dummy_modela"."id" FROM "dummy_modela" LEFT OUTER JOIN
 "dummy_modelb" ON ( "dummy_modela"."id" = "dummy_modelb"."a_id" ) WHERE
 (NOT ("dummy_modela"."id" IN (SELECT U1."a_id" AS Col1 FROM "dummy_modelb"
 U1 WHERE U1."field_f" = 3)) OR ("dummy_modelb"."field_f" = 3 AND
 "dummy_modelb"."field_g" >= 50))'
 }}}

 Generates quite different SQL, which returns different results.

 Would like to be sure a fix for #14645 fixes this case.

--

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

-- 
You received this message

Re: [Django] #12856: Decide on public API/documentation for form.BoundField attributes

2015-08-10 Thread Django

#12856: Decide on public API/documentation for form.BoundField attributes
-+-
 Reporter:  mnbayazit|Owner:  MoritzS
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  boundfield required  | Triage Stage:  Accepted
  is_hidden auto_id  |
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by MoritzS):

 * owner:  nobody => MoritzS
 * needs_better_patch:  1 => 0
 * has_patch:  1 => 0
 * status:  new => assigned


--
Ticket URL: 
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.9307350a070acfae0cc6f676fcfa4d54%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25254: Allow control over json.dumps keyword arguments in JsonResponse

2015-08-10 Thread Django

#25254: Allow control over json.dumps keyword arguments in JsonResponse
-+-
 Reporter:  jaap3|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  json dumps indent| Triage Stage:
  separators jsonresponse|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jaap3):

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


Comment:

 A partial workaround for this is to create a custom encoder class that
 sets the desired values for `indent` and `separators`, this won't work as
 well for other `kwargs` as there are defaults sets in `dumps`.

--
Ticket URL: 
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.f4d8d5da6f16f3ae707928183678e098%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25254: Allow control over json.dumps keyword arguments in JsonResponse

2015-08-10 Thread Django

#25254: Allow control over json.dumps keyword arguments in JsonResponse
-+-
 Reporter:  jaap3|  Owner:  nobody
 Type:  New  | Status:  new
  feature|
Component:  HTTP |Version:  master
  handling   |   Keywords:  json dumps indent separators
 Severity:  Normal   |  jsonresponse
 Triage Stage:   |  Has patch:  0
  Unreviewed |
Easy pickings:  0|  UI/UX:  0
-+-
 Currently `JsonResponse`'s only allows changing the JSON encoder class. It
 would be helpful to allow some/all of the arguments to `json.dumps` .

 In my case I've had the need to set `indent=2`, to get a more readable
 output, and `separators=(',', ':')` to get the most compact output
 possible. Having control over `allow_nan` or `skipkeys` could also be
 useful for some.

--
Ticket URL: 
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/048.2e0406759c3df221875a738dd36f07cd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25253: Migrations do unecessary work when adding `blank=True` to M2M field on MySQL

2015-08-10 Thread Django

#25253: Migrations do unecessary work when adding `blank=True` to M2M field on
MySQL
+--
 Reporter:  trecouvr|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.8
 Severity:  Normal  |   Keywords:  migrations m2m mysql
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+--
 When running a MySQL migration to add `blank=True` on a `ManyToManyField`,
 Django drops the FK constraints on the join table and creates them back.


 Here is the changeset for models.py:

 {{{
 from django.contrib.auth.models import User
 from django.db import models


 class Banana(models.Model):
 -users = models.ManyToManyField(User)
 +users = models.ManyToManyField(User, blank=True)
 }}}


 And here the corresponding migration:

 {{{
 ..
 operations = [
 migrations.AlterField(
 model_name='banana',
 name='users',
 field=models.ManyToManyField(to=settings.AUTH_USER_MODEL,
 blank=True),
 ),
 ]
 ..
 }}}



 The resulting sql for MySQL backend is:

 {{{
 ALTER TABLE `myproject_banana_users` DROP FOREIGN KEY
 `myproject_banana_users_user_id_93c9ecfd1bc0dc2_fk_auth_user_id`;
 ALTER TABLE `myproject_banana_users` ADD CONSTRAINT
 `myproject_banana_users_user_id_60a2450416dd445f_fk_auth_user_id` FOREIGN
 KEY (`user_id`) REFERENCES `auth_user` (`id`);
 ALTER TABLE `myproject_banana_users` DROP FOREIGN KEY
 `myproject_bana_banana_id_4be506ef34515098_fk_myproject_banana_id`;
 ALTER TABLE `myproject_banana_users` ADD CONSTRAINT
 `myproject_bana_banana_id_43426c15f7d142f5_fk_myproject_banana_id` FOREIGN
 KEY (`banana_id`) REFERENCES `myproject_banana` (`id`);
 }}}

 I checked on PostgreSQL the resulting sql is empty, which looks good to me
 since there is no change to issue to the database.

--
Ticket URL: 
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.afa4f0f63c0d12dc2b20ae00c6761d97%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

52 matches

Mail list logo