Re: [Django] #21760: prefetch_related uses an inefficient query to get the related fk data

[Django]

#21760: prefetch_related uses an inefficient query to get the related fk data
-+-
 Reporter:  valtron2000@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  prefetch_related |  Needs documentation:  0
  ForeignKey |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

 * stage:  Unreviewed => Accepted


Comment:

 Seems OK to me.

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

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

Re: [Django] #21760: prefetch_related uses an inefficient query to get the related fk data

[Django]

#21760: prefetch_related uses an inefficient query to get the related fk data
-+-
 Reporter:  valtron2000@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  prefetch_related |  Unreviewed
  ForeignKey |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by loic84):

 * cc: loic@… (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/079.11415ff815eb0e668d55f2a6e3bda3ba%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21477: Rename pre/post_migrate argument db to using

[Django]

#21477: Rename pre/post_migrate argument db to using
--+
 Reporter:  akaariai  |Owner:  syphar
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  Version:  master
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by loic84):

 * severity:  Normal => Release blocker


Comment:

 These patches also address the deprecation of the pre/post_syncdb signals
 which IMO should be part of Django 1.7.

 Bumping the severity to Release Blocker as a result, please revert if you
 think 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/066.549169e214ed7115e3c858c463641649%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21760: prefetch_related uses an inefficient query to get the related data

[Django]

#21760: prefetch_related uses an inefficient query to get the related data
--+
 Reporter:  valtron2000@… |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.6
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  prefetch_related
Easy pickings:  0 |  Has patch:  0
  |  UI/UX:  0
--+
 Consider the following models and query:

 {{{
 #!python

 class Author(models.Model):
 name = models.CharField(max_length = 20)

 class Book(models.Model):
 name = models.CharField(max_length = 20)
 author = models.ForeignKey(Author, related_name = 'books')

 Book.objects.all().prefetch_related('author')
 }}}

 The query I'd expect to be issued by the `prefetch_related` is:

 {{{
 #!sql

 SELECT * FROM author
 WHERE id IN (... the author_ids of the books from the main query ...)
 }}}

 However, the query that actually get executed are:

 {{{
 #!sql

 SELECT a.* FROM author a INNER JOIN book b ON (a.id = b.author_id)
 WHERE b.id IN (...  the ids of the books from the main query ...)
 }}}

 There are two problems with this approach:

 1. It does a join, which wouldn't be necessary if `author_id`s were used
 instead of `book.id`s
 2. When one uses `prefetch_related` in such a case (that is, to prefetch a
 single fk per object rather than a many to many) instead of
 `select_related`, it's usually because there are many primary objects
 (books) and few unique related objects (authors); `select_related`,
 despite getting all the data in one query, could end up returning much
 more data than is needed because the related objects are duplicated many
 times over, and will be slower overall. Thus, the approach currently used
 by `prefetch_related` ends up using the set of ids that will almost always
 be larger (the book ids, rather than the authors).

 The reverse case (`Author.objects.all().prefetch_related('books')`) does
 the efficient, joinless query I'd expect -- namely:

 {{{
 #!sql

 SELECT * FROM book
 WHERE author_id IN (... the ids of the authors from the main query ...)
 }}}

 I've attached a sample project with a 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/064.71e2c39f50d8da096b25274c41dd975d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21760: prefetch_related uses an inefficient query to get the related fk data (was: prefetch_related uses an inefficient query to get the related data)

[Django]

#21760: prefetch_related uses an inefficient query to get the related fk data
-+-
 Reporter:  valtron2000@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  prefetch_related |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by valtron2000@…):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 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/079.f1a98eb7d44269cfb57572c33e37171f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21760: prefetch_related uses an inefficient query to get the related fk data

[Django]

#21760: prefetch_related uses an inefficient query to get the related fk data
-+-
 Reporter:  valtron2000@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  prefetch_related |  Unreviewed
  ForeignKey |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by valtron2000@…):

 * keywords:  prefetch_related => prefetch_related ForeignKey


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

Re: [Django] #21750: STATIC_ROOT is required in 1.7

[Django]

#21750: STATIC_ROOT is required in 1.7
-+
 Reporter:  aaugustin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  1.6
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by loic84):

 * has_patch:  0 => 1


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

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

Re: [Django] #21750: STATIC_ROOT is required in 1.7

[Django]

#21750: STATIC_ROOT is required in 1.7
-+
 Reporter:  aaugustin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  1.6
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by loic84):

 I'm reasonably confident that this is the best way to deal with the
 immediate issue, so I turned it into a PR:
 https://github.com/django/django/pull/2156.

 On IRC, @jezdez, @mjtamlyn and myself discussed a
 `Storage.check_configured` method that would raise `ImperperlyConfigured`
 if the storage is missing some settings or dependencies. I think the idea
 has merit as a feature of its own but that wouldn't help to solve this
 problem which boils down to: "validate STATIC_ROOT when STATIC_ROOT is
 actually used", as opposed to "validate STATIC_ROOT when the storage is
 used".

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

Re: [Django] #21759: admindocs doesn't restructuredtext-ify model docstrings

[Django]

#21759: admindocs doesn't restructuredtext-ify model docstrings
---+--
 Reporter:  chris@…|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.5
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  admindocs  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timo):

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


Comment:

 Duplicate of #5405 -- feel free to work on polishing the pull request
 there if you'd like to help out.

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

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

[Django] #21759: admindocs doesn't restructuredtext-ify model docstrings

[Django]

#21759: admindocs doesn't restructuredtext-ify model docstrings
---+---
 Reporter:  chris@…|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.5
 Severity:  Normal |   Keywords:  admindocs
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 e.g.
 {{{
 class Bar:
   pass

 class Foo:
   """
   Refers to :model:`app.Bar`.
   """
   pass
 }}}
 does not create a link to the {{{Bar}}} model. The documentation doesn't
 say anything about this; it looks like the raw docstring from
 {{{model.__doc__}}} is passed straight to the template.

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

[django/django] 9eb160: Fixed #12571 -- Attached originating WSGIRequest t...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 9eb16031ca837624433c49646289b50f9566a25d
  
https://github.com/django/django/commit/9eb16031ca837624433c49646289b50f9566a25d
  Author: Unai Zalakain 
  Date:   2014-01-09 (Thu, 09 Jan 2014)

  Changed paths:
M django/test/client.py
M docs/releases/1.7.txt
M docs/topics/testing/tools.txt
M tests/test_client/tests.py

  Log Message:
  ---
  Fixed #12571 -- Attached originating WSGIRequest to test client responses.

Originating WSGIRequests are now attached to the ``wsgi_request`` attribute of
the ``HttpResponse`` returned by the testing client.

Thanks rvdrijst for the suggestion.


-- 
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/52cf36438c206_4ec3f3fd5473088%40hookshot-fe6-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12571: Test client doesn't set WSGIRequest instance on response

[Django]

#12571: Test client doesn't set WSGIRequest instance on response
-+-
 Reporter:  rvdrijst |Owner:
 Type:  Bug  |  unaizalakain
Component:  Testing framework|   Status:  closed
 Severity:  Normal   |  Version:  master
 Keywords:  test client request  |   Resolution:  fixed
  response WSGIRequest   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"9eb16031ca837624433c49646289b50f9566a25d"]:
 {{{
 #!CommitTicketReference repository=""
 revision="9eb16031ca837624433c49646289b50f9566a25d"
 Fixed #12571 -- Attached originating WSGIRequest to test client responses.

 Originating WSGIRequests are now attached to the ``wsgi_request``
 attribute of
 the ``HttpResponse`` returned by the testing client.

 Thanks rvdrijst for the suggestion.
 }}}

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

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

Re: [Django] #21751: Django doesn't do a good job of closing cursors

[Django]

#21751: Django doesn't do a good job of closing cursors
-+-
 Reporter:  manfre   |Owner:  manfre
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by manfre):

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

 Pull request is ready for initial 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/064.1abea97b55402fb5c195ef14938e212d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21758: Document South->built-in migrations transition

[Django]

#21758: Document South->built-in migrations transition
--+
   Reporter:  kmtracey|  Owner:
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  master
   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   |
--+
 Neither the 1.7 release notes nor
 https://docs.djangoproject.com/en/dev/topics/migrations/ says anything
 about how someone who has a project currently using south for schema
 migrations would transition to using the built-in Migrations of 1.7.

 I assumed you could upgrade to 1.7 yet continue with existing south until
 you were ready to make the switch, at which point you'd essentially drop
 all the history you have with south and switch over to the new way going
 forward. Is that the plan?

 However existing south doesn't work with current master, due to:

 {{{
 (django17-test) kmtracey@caktus006 16:42:54: ~/projects/playground
 --> ./manage.py migrate --list
 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/home/kmtracey/django/git-
 django/django/core/management/__init__.py", line 426, in
 execute_from_command_line
 utility.execute()
   File "/home/kmtracey/django/git-
 django/django/core/management/__init__.py", line 418, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/kmtracey/django/git-
 django/django/core/management/__init__.py", line 290, in fetch_command
 klass = load_command_class(app_name, subcommand)
   File "/home/kmtracey/django/git-
 django/django/core/management/__init__.py", line 81, in load_command_class
 module = import_module('%s.management.commands.%s' % (app_name, name))
   File "/usr/lib/python2.7/importlib/__init__.py", line 37, in
 import_module
 __import__(name)
   File "/home/kmtracey/.virtualenvs/django17-test/local/lib/python2.7
 /site-packages/south/management/commands/__init__.py", line 12, in
 
 from south.hacks import hacks
   File "/home/kmtracey/.virtualenvs/django17-test/local/lib/python2.7
 /site-packages/south/hacks/__init__.py", line 8, in 
 from south.hacks.django_1_0 import Hacks
   File "/home/kmtracey/.virtualenvs/django17-test/local/lib/python2.7
 /site-packages/south/hacks/django_1_0.py", line 8, in 
 from django.db.models.loading import cache
 ImportError: cannot import name cache
 }}}

 That strikes me as a problem introduced by the app-loading refactor...but
 due to lack of doc on how people who use south are supposed to move up to
 1.7 I don't know if that's a problem that should be fixed in a release of
 south before 1.7 goes out or not. The first thing that's needed is some
 doc on how people are supposed to make this transition.

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

Re: [Django] #21750: STATIC_ROOT is required in 1.7

[Django]

#21750: STATIC_ROOT is required in 1.7
-+
 Reporter:  aaugustin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  1.6
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by loic84):

 This should address the backward compatibility issues while preserving the
 fix for #21581: https://github.com/loic/django/compare/ticket21750.

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

Re: [Django] #21721: Python 3.4 support

[Django]

#21721: Python 3.4 support
-+
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Python 3 |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by akaariai):

 Any chance you can run djangobench for this? IIRC model_init_self_signals
 will benchmark signal sending.

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

Re: [Django] #21754: Object discrepency between python2.x and python3.x with model field "to_python" and "get_prep_value" when retrieving object from database

[Django]

#21754: Object discrepency between python2.x and python3.x with model field
"to_python" and "get_prep_value" when retrieving object from database
---+--
 Reporter:  troygrosfield  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Python 3   |  Version:  1.6
 Severity:  Normal |   Resolution:  fixed
 Keywords:  python3| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by troygrosfield):

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


Comment:

 That did the trick!  Thanks @mjtamlyn!  Here's the working change for the
 example above:

 {{{
 from django.utils.six import with_metaclass

 class IntStoredAsStringField(with_metaclass(models.SubfieldBase,
 models.CharField)):

 def __init__(self, max_length=2000, *args, **kwargs):
 super(IntStoredAsStringField,
 self).__init__(max_length=max_length,
  *args, **kwargs)

 def to_python(self, value):
 if isinstance(value, int):
 return value

 return int(value)

 def get_prep_value(self, value):
 return smart_text(value)
 }}}

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

Re: [Django] #21757: Allow modifying the SQL generated by lookups

[Django]

#21757: Allow modifying the SQL generated by lookups
-+-
 Reporter:  shmishleniy@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  postgresql like  |  Patch needs improvement:  0
  ilike icontains|UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by mjtamlyn):

 Seems there's not much difference in the indexed case these days, but
 there is in the non indexed case which is likely what people will do a
 lot. So that resolves that the default behaviour will stay as is, this
 ticket is not just about making it possible to change how `__icontains`
 etc work for your use case as akaariai dsicussed.

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

Re: [Django] #21757: Allow modifying the SQL generated by lookups

[Django]

#21757: Allow modifying the SQL generated by lookups
-+-
 Reporter:  shmishleniy@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  postgresql like  |  Patch needs improvement:  0
  ilike icontains|UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by shmishleniy@…):

 Replying to [comment:2 mjtamlyn]:
 > At the moment I believe your tests are showing the second and third in
 that list, which is a little unfair as one utilises an index and the other
 does a sequential scan.
 Yes you are right. Added screenshots in attachments :)

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

Re: [Django] #21753: allow generic editing views to use `form_class` and `fields` together

[Django]

#21753: allow generic editing views to use `form_class` and `fields` together
-+-
 Reporter:  gabejackson  |Owner:
 Type:  New feature  |  gabejackson
Component:  Generic views|   Status:  new
 Severity:  Normal   |  Version:  master
 Keywords:  generic edit views   |   Resolution:
  form_class fields ModelForm| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by gabejackson):

 Main argument from discussion with mjtamyln: "one of the common criticisms
 of our CBVs is that they have too many customisation points and do too
 much magic (or implicit behaviour). Let's not add any more"
 Generally fatter forms and thinner views are recommended. The above use-
 case should be solved by subclassing ModelForm and adapting the fields,
 then use the new ModelForm in the View.

 Dynamic form creation dependent of request data can be done by passing
 data to Form.__init__() and adapting the fields there. Alternatively one
 can change the form_class in get_form_class by doing something like:
 return SuperForm if self.request.user.is_superuser else NormalForm.

 It should be noted in the docs that `fields` was added to View from a
 security point of view, not for customization of forms.

 The question remains if using form_class and fields together should raise
 an ImproperlyConfigured or just fail silently. Compare this to the
 approach of using queryset vs model in a View: This will fail silently
 preferring queryset over model. This seems logical because queryset allows
 more fine-grained control. Does the same hold true for fields and
 form_class? One might expect that fields will just work with form_class,
 or one might make the reverse assumption that fields defined in form_class
 will override what is in fields of the View.

 to be discussed.

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

Re: [Django] #21757: Allow modifying the SQL generated by lookups

[Django]

#21757: Allow modifying the SQL generated by lookups
-+-
 Reporter:  shmishleniy@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  postgresql like  |  Patch needs improvement:  0
  ilike icontains|UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by shmishleniy@…):

 Thanks to all for response.
 Custom lookups it's great feature.

 Create two indexes for normal case and for UPPER case not good solution
 for me becouse I will waste 2 time more space and no increase performance.

 Cases:
 1. Performance of ILIKE without index
 2. Performance of LIKE UPPER without index
 3. Performance of ILIKE with the relevant index
 4. Performance of LIKE with index from case 3 (case sensitive search)
 5. Performance of LIKE UPPER with the relevant index

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

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

Re: [Django] #21371: Admin templates use a `bodyclass` block without ever calling super.

[Django]

#21371: Admin templates use a `bodyclass` block without ever calling super.
-+-
 Reporter:  Keryn Knight |Owner:  resry
   |   Status:  assigned
 Type:   |  Version:  master
  Cleanup/optimization   |   Resolution:
Component:  contrib.admin| Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-

Comment (by pouete):

 Hello !
 I have a [[https://github.com/django/django/pull/2152|pull request]] to
 address this ticket !



 Fix+test 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/095.2017fdc37ed2262fe2ad2b0a73df9af3%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21752: forms.NumberInput - "step" always forced to "any", cannot modify

[Django]

#21752: forms.NumberInput - "step" always forced to "any", cannot modify
--+
 Reporter:  orcein@…  |Owner:  claudep
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  1.6
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * has_patch:  0 => 1


Comment:

 Here's the most straightforward way to fix this 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/074.15480c2e1e5cf1bffd715b14c2dccf7a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21752: forms.NumberInput - "step" always forced to "any", cannot modify

[Django]

#21752: forms.NumberInput - "step" always forced to "any", cannot modify
--+
 Reporter:  orcein@…  |Owner:  claudep
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  1.6
 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 claudep):

 * owner:  nobody => claudep
 * status:  new => assigned
 * stage:  Unreviewed => Accepted


Comment:

 I can confirm. I'll investigate this 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/074.496aec166737da8f57722576f8c36268%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21754: Object discrepency between python2.x and python3.x with model field "to_python" and "get_prep_value" when retrieving object from database

[Django]

#21754: Object discrepency between python2.x and python3.x with model field
"to_python" and "get_prep_value" when retrieving object from database
---+--
 Reporter:  troygrosfield  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Python 3   |  Version:  1.6
 Severity:  Normal |   Resolution:
 Keywords:  python3| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by mjtamlyn):

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


Comment:

 `__metaclass__` does nothing on python 3. Can you try your example using
 http://pythonhosted.org/six/#six.with_metaclass?

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

Re: [Django] #21753: allow generic editing views to use `form_class` and `fields` together

[Django]

#21753: allow generic editing views to use `form_class` and `fields` together
-+-
 Reporter:  gabejackson  |Owner:
 Type:  New feature  |  gabejackson
Component:  Generic views|   Status:  new
 Severity:  Normal   |  Version:  master
 Keywords:  generic edit views   |   Resolution:
  form_class fields ModelForm| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mjtamlyn):

 * component:  Forms => Generic views
 * 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/069.861cd09531a8b33a7c159327c45269d6%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21753: allow generic editing views to use `form_class` and `fields` together

[Django]

#21753: allow generic editing views to use `form_class` and `fields` together
-+-
 Reporter:  gabejackson  |Owner:
 Type:  New feature  |  gabejackson
Component:  Forms|   Status:  new
 Severity:  Normal   |  Version:  master
 Keywords:  generic edit views   |   Resolution:
  form_class fields ModelForm| Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by mjtamlyn):

 I would suggest this should only give a warning, possibly even
 `ImproperlyConfigured`, not change the form. From options a) and  b) above
 it is not clear what the "correct" approach is - and either has the
 potential to confuse. I do not want class based views to fall into a trap
 of allowing myriad hooks to customise the form class, like `form.Meta`
 allows with fields. The reason why `fields` was introduced on these views
 is to allow you to ensure security when using an auto generated
 `form_class`. If you're setting the `form_class`, you can obviously set up
 the `form_class` correctly.

 Personally, I'd rather get rid of automatic `form_class` generation all
 together, but that's another story.

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

Re: [Django] #21721: Python 3.4 support

[Django]

#21721: Python 3.4 support
-+
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Python 3 |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by apollo13):

 Latest version at https://github.com/apollo13/django/compare/signals

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

Re: [Django] #21757: Allow modifying the SQL generated by lookups

[Django]

#21757: Allow modifying the SQL generated by lookups
-+-
 Reporter:  shmishleniy@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  postgresql like  |  Patch needs improvement:  0
  ilike icontains|UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by mjtamlyn):

 Reading your `EXPLAIN` output, the easiest thing to do will be for you to
 add a PG functional index to that column on `UPPER(value)`. According to
 the benchmarks in the old ticket (though it is possible PG's optimisations
 have changed since then) this will actually come out faster than your
 ILIKE query you have at the moment. You would need to create that index by
 hand (or using South or db.migrations in 1.7). It would be interesting to
 see an updated version of the benchmarks from #3575 as they may be
 different with Postgres 9 than it was with whatever version of PG we had 6
 years ago. I would still be nervous about changing the default though as
 this could break optimisations other people have put in place.

 A full benchmark would need to show:
 - Performance of ILIKE without index
 - Performance of LIKE UPPER without index
 - Performance of ILIKE with the relevant index
 - Performance of LIKE UPPER with the relevant index

 At the moment I believe your tests are showing the second and third in
 that list, which is a little unfair as one utilises an index and the other
 does a sequential scan.

 I do not believe the documentation needs to be updated - this kind of
 optimisation is an advanced use case.

 There are a couple of ideas in progress which will result in making this
 kind of thing easier. One is custom lookups (#16187), the other is custom
 indexes (can't remember the number).

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

Re: [Django] #21757: Allow modifying the SQL generated by lookups (was: orm limitations)

[Django]

#21757: Allow modifying the SQL generated by lookups
-+-
 Reporter:  shmishleniy@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  postgresql like  |  Patch needs improvement:  0
  ilike icontains|UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  1.6 => master
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 This issue will be hopefully fixed with custom lookups (#16187,
 https://github.com/django/django/pull/2019). Using custom lookups you
 could write your own lookup 'ilike', or override how icontains works
 (either by writing a custom IContains lookup, or by overriding the default
 implementation with @add_implementation).

 I'm going to mark this as accepted, with the meaning that we should allow
 some easier way for users to override the SQL generated for icontains (and
 for other lookups for that matter). I don't think we should go alter the
 default implementation, I believe the optimization could lead to
 performance problems for other users.

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

Re: [Django] #21750: STATIC_ROOT is required in 1.7

[Django]

#21750: STATIC_ROOT is required in 1.7
-+
 Reporter:  aaugustin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  1.6
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by mjtamlyn):

 The existing patch to #21581 seems to be a major inconvenience to me, and
 is certainly unreleasable on 1.6.x. - we can't make projects which run (or
 test suites which run) suddenly start breaking. I certainly have projects
 where the `STORAGE_BACKEND` is deliberately configured different during
 the tests (and sometimes even for local dev) to avoid the possibility of
 overwriting the files on S3.

 It seems reasonable that `collectstatic` should do the check, but should
 do so by asking the `STORAGE_BACKEND` whether it is properly configured
 before running the command - thus not leaking the implementation details.

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