Re: [Django] #19843: ORM generate dupes when filtering twice on related objects

[Django]

#19843: ORM generate dupes when filtering twice on related objects
-+-
 Reporter:  tonnzor  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ioreku):

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


Comment:

 [https://docs.djangoproject.com/en/dev/topics/db/queries/#s-spanning-
 multi-valued-relationships This] explains the results you are getting.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16116: Compress cache data

[Django]

#16116: Compress cache data
-+-
 Reporter:  bjourne  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Cache system)  |  Version:  1.3
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by lucmult):

 PR: with the patch.

 Still need docs though.

 Is there a way to test it ?

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

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

[django/django] 4b9fa4: Avoided related_name conflicts in tests

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 4b9fa49bc0cf5d2e01b6b98dec6d23fed774f254
  
https://github.com/django/django/commit/4b9fa49bc0cf5d2e01b6b98dec6d23fed774f254
  Author: Anssi Kääriäinen 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
M tests/regressiontests/aggregation_regress/models.py
M tests/regressiontests/aggregation_regress/tests.py

  Log Message:
  ---
  Avoided related_name conflicts in tests



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19844: Uniqueness validation of USERNAME_FIELD should be overridable.

[Django]

#19844: Uniqueness validation of USERNAME_FIELD should be overridable.
-+-
 Reporter:  josh@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.5-rc-1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by russellm):

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


Comment:

 So... you want to allow people to log in, and be uniquely identifiable,
 but without providing a unique identifier? That sounds... interesting.

 I'm afraid too much of Django's internals relies on username being unique
 to be able to relax this condition. Django's login form uses this unique
 identifier on login forms (specifically because it is unique), so even if
 we relaxed the validation condition, you wouldn't be able to use Django's
 login form. You also won't be able to use the auth Model backend, or
 significant parts of Django's admin, or anything else that asks the simple
 question "Which user do you want to operate on" -- at least, not out of
 the box.

 However, keep in mind that the username field doesn't have to be the
 user's name, or their login. It just needs to be a unique identifier.

 From the sound of it, you might be able to get away with using the model's
 primary key as your USERNAME_FIELD. You will need to set up your login
 forms to do a search on email, rather than the username field - but you'd
 have to write your own login form anyway. The existing login form isn't
 going to work, because it assumes that the username field is unique, so
 there's no real change in the effort involved here. (I haven't actually
 tried this though, so there might be some other interesting side effects).

 I'm not a fan of adding a setting or flag to allow this error to be
 ignored -- something is either an error or it isn't. And if you don't have
 a way to uniquely identify someone, you haven't got a unique object. A
 warning falls in a simliar bucket to me -- warnings are universally
 ignored by the people who need to pay attention to them; errors force you
 to fix the problem.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 607772: Removed accidentally committed file

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 607772b942010d2b237c95d2ba74c958986def04
  
https://github.com/django/django/commit/607772b942010d2b237c95d2ba74c958986def04
  Author: Anssi Kääriäinen 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
R tests/tmp.txt

  Log Message:
  ---
  Removed accidentally committed file



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19846: Simplify BlockContext code with defaultdict

[Django]

#19846: Simplify BlockContext code with defaultdict
--+
 Reporter:  FunkyBob  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Template system   |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  1 |  UI/UX:  0
--+
 Just a tiny cleanup that likely gives better performance... replace the
 manual work with a defaultdict(list):

 {{{
 diff --git a/django/template/loader_tags.py
 b/django/template/loader_tags.py
 index d295d05..6dbe49f 100644
 --- a/django/template/loader_tags.py
 +++ b/django/template/loader_tags.py
 @@ -5,6 +5,8 @@ from django.template.loader import get_template
  from django.utils.safestring import mark_safe
  from django.utils import six

 +from collections import defaultdict
 +
  register = Library()

  BLOCK_CONTEXT_KEY = 'block_context'
 @@ -15,19 +17,16 @@ class ExtendsError(Exception):
  class BlockContext(object):
  def __init__(self):
  # Dictionary of FIFO queues.
 -self.blocks = {}
 +self.blocks = defaultdict(list)

  def add_blocks(self, blocks):
  for name, block in six.iteritems(blocks):
 -if name in self.blocks:
 -self.blocks[name].insert(0, block)
 -else:
 -self.blocks[name] = [block]
 +self.blocks[name].insert(0, block)

  def pop(self, name):
  try:
  return self.blocks[name].pop()
 -except (IndexError, KeyError):
 +except IndexError:
  return None

  def push(self, name, block):
 @@ -36,7 +35,7 @@ class BlockContext(object):
  def get_block(self, name):
  try:
  return self.blocks[name][-1]
 -except (IndexError, KeyError):
 +except IndexError:
  return None

  class BlockNode(Node):
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10870: Aggregates with joins ignore extra filters provided by setup_joins

[Django]

#10870: Aggregates with joins ignore extra filters provided by setup_joins
-+-
 Reporter:  fas  |Owner:  fas
 Type:  Bug  |   Status:  closed
Component:  ORM aggregation  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  orm, aggregation,| Triage Stage:  Accepted
  join, contenttypes, filter |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [changeset:"3e71368423b41c9418117328216e66f95cbaab03"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3e71368423b41c9418117328216e66f95cbaab03"
 Fixed #10870 -- Added aggreation + generic reverse relation 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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 3e7136: Fixed #10870 -- Added aggreation + generic reverse...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 3e71368423b41c9418117328216e66f95cbaab03
  
https://github.com/django/django/commit/3e71368423b41c9418117328216e66f95cbaab03
  Author: Florian Hahn 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
M tests/regressiontests/aggregation_regress/models.py
M tests/regressiontests/aggregation_regress/tests.py

  Log Message:
  ---
  Fixed #10870 -- Added aggreation + generic reverse relation test



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19582: Add tutorial on static files

[Django]

#19582: Add tutorial on static files
--+
 Reporter:  jpic  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  docs, static files| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by jpic):

 * cc: jpic (added)


Comment:

 Here some things I'd like to change.

 - given the general confusion on how to add a static file to a
   project, I would rewrite the first part so that it goes straight
   to the point: ie. "Install a static file in your project:
   how to add jQuery"
 - second part of the tutorial would be deployment,
 - third part would be using app/static subfolder,
 - wording issues, for example "assets" is a word I (as a self
   learner, non english) learnt from reading about Rails, so I
   think it can be confusing for other users. It would be better to
   name "static files" just "static files"

 Also, I have tried django 1.5 starter project: it looks like every django
 project that will need at least one static file (most projects) will have
 to setup `STATICFILES_DIRS=[os.path.join(BASE_DIR, 'static')]`. What's the
 point ? Couldn't we change that and make it default ?

 I mean, it could potentially be as easy as:

 > drop style.css in `your_project/static` and use
 > `{{ STATIC_URL }}style.css` or `{% static 'style.css' %}` in the
 template

 (Sorry I had totally forgotten about this and forgot to CC myself
 ... Note that I've read both document and I can ensure
 that every point listed by Zed has a response in the new
 tutorial.)

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16116: Compress cache data

[Django]

#16116: Compress cache data
-+-
 Reporter:  bjourne  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Cache system)  |  Version:  1.3
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by lucmult):

 As a side note.

 python-memcached has support for mixed values (zipped and not zipped), so
 it's safe to change this option at any time.

 Also, it compress only when bigger than specified on `MIN_COMPRESS_LEN`,
 so one concerned by zlib overhead can increase this value, for somebody
 concerned about network traffic on memcached can make it lower.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16116: Compress cache data

[Django]

#16116: Compress cache data
-+-
 Reporter:  bjourne  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Cache system)  |  Version:  1.3
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by lucmult):

 * cc: lucmult (added)
 * ui_ux:   => 0


Comment:

 Hello guys,

 Last week we run on this problem of memcache limitation and started to
 have much more CPU load on our server due our biggest pages weren't being
 cached.

 python-memcached has support to zip (when zlib is available):

 http://bazaar.launchpad.net/~python-memcached-team/python-
 memcached/trunk/view/head:/memcache.py#L763

 I'm willing to submit a patch to `MemcachedCache` backend to be able to
 configure it on settings.

 settings:
 {{{#!python
 CACHES = {
 'default': {
 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
 'LOCATION': ['127.0.0.1:11211'],
 'OPTIONS': {
 'CLIENT_OPTIONS': {'server_max_value_length': 67108864,
 'pickleProtocol': 2},
 'MIN_COMPRESS_LEN': 500,
 }
 }
 }
 }}}

 `server_max_value_length` is useful because python-memcached uses it to
 decide if it should ignore the value.  It's default to `1024*1024`
 http://bazaar.launchpad.net/~python-memcached-team/python-
 memcached/trunk/view/head:/memcache.py#L775

 In the docs I would suggest our users to set with the value got from
 memcache stats:

 {{{#!bash
 $ echo "stats settings" | nc localhost 11211`
 STAT maxbytes 67108864
 ...

 }}}
 Although this hasn't shown as the real limit on my local test :(
 If the application send a value bigger than memcache can handle it just
 respond as data is too big to store, no exception is raised, cache is only
 ignored (as we have currently).

 Our usage of `MIN_COMPRESS_LEN` has shown a significant decrease of
 network traffic between django server and memcached server.

 This fix would benefit more 2 tickets:
 Memcached session "forgets" big values -
 https://code.djangoproject.com/ticket/16358
 Memcached using pickle highest protocol -
 https://code.djangoproject.com/ticket/16378

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19837: Regression in QuerySet.exclude and many to many

[Django]

#19837: Regression in QuerySet.exclude and many to many
-+-
 Reporter:  timo |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [changeset:"b4492a8ca4a7ae4daa3a6b03c3d7a845fad74931"]:
 {{{
 #!CommitTicketReference repository=""
 revision="b4492a8ca4a7ae4daa3a6b03c3d7a845fad74931"
 Fixed #19837 -- Refactored split_exclude() join generation

 The refactoring mainly concentrates on making sure the inner and outer
 query agree about the split position. The split position is where the
 multijoin happens, and thus the split position also determines the
 columns used in the "WHERE col1 IN (SELECT col2 from ...)" condition.

 This commit fixes a regression caused by #10790 and commit
 69597e5bcc89aadafd1b76abf7efab30ee0b8b1a. The regression was caused
 by wrong cols in the split position.
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] b4492a: Fixed #19837 -- Refactored split_exclude() join ge...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: b4492a8ca4a7ae4daa3a6b03c3d7a845fad74931
  
https://github.com/django/django/commit/b4492a8ca4a7ae4daa3a6b03c3d7a845fad74931
  Author: Anssi Kääriäinen 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
M django/db/models/sql/datastructures.py
M django/db/models/sql/query.py
M tests/regressiontests/queries/models.py
M tests/regressiontests/queries/tests.py
A tests/tmp.txt

  Log Message:
  ---
  Fixed #19837 -- Refactored split_exclude() join generation

The refactoring mainly concentrates on making sure the inner and outer
query agree about the split position. The split position is where the
multijoin happens, and thus the split position also determines the
columns used in the "WHERE col1 IN (SELECT col2 from ...)" condition.

This commit fixes a regression caused by #10790 and commit
69597e5bcc89aadafd1b76abf7efab30ee0b8b1a. The regression was caused
by wrong cols in the split position.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] ffcfb1: Added required methods in BaseDatabaseWrapper.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ffcfb19f47f5995406003cffca24cf62c6d234a8
  
https://github.com/django/django/commit/ffcfb19f47f5995406003cffca24cf62c6d234a8
  Author: Aymeric Augustin 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
M django/db/backends/__init__.py

  Log Message:
  ---
  Added required methods in BaseDatabaseWrapper.

I should have included this in 29628e0b6e5b1c6324e0c06cc56a49a5aa0747e0.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18135: Sleeping Database Connections on Startup with MySQL

[Django]

#18135: Sleeping Database Connections on Startup with MySQL
-+-
 Reporter:  Mnewman  |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  MySQL|  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"aea98e8c5357b15da214af311e8cb74b1503f958"]:
 {{{
 #!CommitTicketReference repository=""
 revision="aea98e8c5357b15da214af311e8cb74b1503f958"
 Simplified MySQL version checking.

 Django used to check the version of MySQL before handling the first
 request, which required:
 - opening a connection
 - closing it, to avoid holding it idle until the first request.

 This code isn't necessary any longer since Django dropped support for
 some versions of MySQL, and other database backends don't implement a
 similar dance. For consistency and maintenability, remove it.

 Reverts 4423757c0c50afbe2470434778c8d5e5b4a70925.

 Closes #18135.
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15119: MySQL backend generates unnecessary commands

[Django]

#15119: MySQL backend generates unnecessary commands
-+-
 Reporter:  lukesneeringer   |Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.2
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"282b2f40cd0aa09815001e178f60c9e71667d847"]:
 {{{
 #!CommitTicketReference repository=""
 revision="282b2f40cd0aa09815001e178f60c9e71667d847"
 Fixed #15119 -- Stopped pinging the MySQL server.
 }}}

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

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

[django/django] aea98e: Simplified MySQL version checking.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: aea98e8c5357b15da214af311e8cb74b1503f958
  
https://github.com/django/django/commit/aea98e8c5357b15da214af311e8cb74b1503f958
  Author: Aymeric Augustin 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
M django/db/backends/mysql/base.py
M tests/regressiontests/backends/tests.py

  Log Message:
  ---
  Simplified MySQL version checking.

Django used to check the version of MySQL before handling the first
request, which required:
- opening a connection
- closing it, to avoid holding it idle until the first request.

This code isn't necessary any longer since Django dropped support for
some versions of MySQL, and other database backends don't implement a
similar dance. For consistency and maintenability, remove it.

Reverts 4423757c0c50afbe2470434778c8d5e5b4a70925.

Closes #18135.


  Commit: 282b2f40cd0aa09815001e178f60c9e71667d847
  
https://github.com/django/django/commit/282b2f40cd0aa09815001e178f60c9e71667d847
  Author: Aymeric Augustin 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
M django/db/backends/__init__.py
M django/db/backends/mysql/base.py

  Log Message:
  ---
  Fixed #15119 -- Stopped pinging the MySQL server.


  Commit: 7b8529d206731bab01855a60f4a6f84e4221f2e1
  
https://github.com/django/django/commit/7b8529d206731bab01855a60f4a6f84e4221f2e1
  Author: Aymeric Augustin 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
M django/db/backends/mysql/base.py

  Log Message:
  ---
  Removed duplicate caching of mysql_version.

The manual caching in self.server_version and the cached_property
decorator are redundant.


  Commit: 21765c0a6c7cece4d052c8c7af6022ac9c61b7cf
  
https://github.com/django/django/commit/21765c0a6c7cece4d052c8c7af6022ac9c61b7cf
  Author: Aymeric Augustin 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
M django/db/backends/postgresql_psycopg2/base.py

  Log Message:
  ---
  Implemented PostgreSQL version as a cached property.


Compare: https://github.com/django/django/compare/29628e0b6e5b...21765c0a6c7c

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14571: Update jQuery

[Django]

#14571: Update jQuery
--+
 Reporter:  robhudson |Owner:  dArignac
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.admin |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:  jquery sprintnov13| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  1
--+

Comment (by claudep):

 Unless someone opposes, I will update the patch to current 1.9.1 version
 of jQuery and commit it (as long as all current Selenium tests pass). The
 forthcoming sprint might also be a good opportunity to test/fix JS issues.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #3591: add support for custom app_label and verbose_name

[Django]

#3591: add support for custom app_label and verbose_name
--+
 Reporter:  jkocherhans   |Owner:  adrian
 Type:  New feature   |   Status:  reopened
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  1
--+
Changes (by zachborboa+django@…):

 * cc: zachborboa+django@… (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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18135: Sleeping Database Connections on Startup with MySQL

[Django]

#18135: Sleeping Database Connections on Startup with MySQL
-+-
 Reporter:  Mnewman  |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  MySQL|  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Today, I learned that some people indeed run hundreds of thousands of
 Django threads... My comment above is wrong!

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

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

Re: [Django] #19434: Some QuerySet methods not aware of fields added on "extra"

[Django]

#19434: Some QuerySet methods not aware of fields added on "extra"
-+-
 Reporter:  hcarvalhoalves   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by fhahn):

 * cc: flo@… (added)
 * has_patch:  0 => 1
 * version:  1.4 => master


Comment:

 I've started a patch that adds support for filtering fields added by extra
 and created a pull request: https://github.com/django/django/pull/735

 I think something similar has been done to provide support for filtering
 annotations/aggregations

 {{{
 qs.extra(select={'num_plus_one': 'num + 1'}
 qs.filter(num_plus_one=2)
 }}}

 will result in following query:

 {{{
 SELECT (num+1) AS "num_plus_on" ...
 WHERE (num+1) = 2 
 }}}

 In order to avoid quoting of the lvalue of the term in the WHERE part I
 modified WhereNode.add to accept a QueryWrapper (contains the extra sql).
 There's probably a much better way to add an unqouted lvalue to the
 WhereNode, any suggestions/feedback are very appreciated.


 {{{  qs.values('some_alias') }}} worked for me (without modification), but
 I've added a test to check it.

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

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

Re: [Django] #18135: Sleeping Database Connections on Startup with MySQL

[Django]

#18135: Sleeping Database Connections on Startup with MySQL
-+-
 Reporter:  Mnewman  |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  MySQL|  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mnewman):

 I think we are on the same page.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15802: Django stops functioning when the database (PostgreSQL) closes the connection

[Django]

#15802: Django stops functioning when the database (PostgreSQL) closes the
connection
-+-
 Reporter:  Rick.van.Hattem@…|Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  database, postgres,  |  Needs documentation:  0
  postgresql, connection, closed |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15802: Django stops functioning when the database (PostgreSQL) closes the connection

[Django]

#15802: Django stops functioning when the database (PostgreSQL) closes the
connection
-+-
 Reporter:  Rick.van.Hattem@…|Owner:
 Type:  Bug  |  Honza_Kral
Component:  Database layer   |   Status:  new
  (models, ORM)  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  database, postgres,  | Triage Stage:  Accepted
  postgresql, connection, closed |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * status:  reopened => new


-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19845: AUTH_USER_MODEL not accept sub application.

[Django]

#19845: AUTH_USER_MODEL not accept sub application.
---+--
 Reporter:  eltonplima@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.5-rc-1
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 I suspect something's wrong with your model definition. Can you upload
 cadastro/pessoa/models.py?

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19845: AUTH_USER_MODEL not accept sub application.

[Django]

#19845: AUTH_USER_MODEL not accept sub application.
---+--
 Reporter:  eltonplima@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.5-rc-1
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by anonymous):

 In my INSTALLED_APPS i have: "cadastro.pessoa"

 If i set AUTH_USER_MODEL="cadastro.pessoa.Usuario" the exception is
 raised:
 ImproperlyConfigured: AUTH_USER_MODEL must be of the form
 'app_label.model_name'

 If i set AUTH_USER_MODEL="pessoa.Usuario" the exception is raised:
 ImproperlyConfigured: AUTH_USER_MODEL refers to model 'pessoa.Usuario'
 that has not been installed

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19845: AUTH_USER_MODEL not accept sub application.

[Django]

#19845: AUTH_USER_MODEL not accept sub application.
---+--
 Reporter:  eltonplima@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.5-rc-1
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by aaugustin):

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


Comment:

 The app label is the last part of the dotted path to the app. It's the
 usual convention 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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19845: AUTH_USER_MODEL not accept sub application.

[Django]

#19845: AUTH_USER_MODEL not accept sub application.
---+--
 Reporter:  eltonplima@…   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.5-rc-1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 In settings.py to use a custom user AUTH_USER_MODEL i have to set the
 format app_label.model_name.

 But my custom User model is within the following structure
 cadastro.pessoa.Usuario and django is not accepting.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18135: Sleeping Database Connections on Startup with MySQL

[Django]

#18135: Sleeping Database Connections on Startup with MySQL
-+-
 Reporter:  Mnewman  |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  MySQL|  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Replying to [comment:26 Mnewman]:
 > So what happens on sites, like I have, that run millions of concurrents?
 I need hundreds of thousands threads to properly scale. I cannot afford a
 relational database that requires that many open "sleeping" connections.

 Exaggeration doesn't help your credibility. No one's running hundred of
 thousands of Django workers connected to a MySQL database without a
 pooler. And the topic of this ticket isn't persistent connections. At the
 moment, they're just a proposal, open for discussion on the mailing list.

 

 Back to the topic.

 I missed a use case in my previous comment: it's possible to have a MySQL
 database that's only occasionally hit by workers, especially if it isn't
 the primary database. Such a database could support fewer simultaneous
 connections than the total amount of workers.

 In the current codebase, the only place that uses the MySQL server version
 is `sequence_reset_by_name_sql`, and this function is only used by the
 tests. It appears that it was called at import time in previous versions
 of Django, but that isn't true any longer.

 One could argue for keeping this code in case future versions of Django
 introduce MySQL-version-dependent code that's evaluated at compile time,
 but in general, unnecessary code hurts maintainability.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18447: LazyObject doesn't unwrap on dict access

[Django]

#18447: LazyObject doesn't unwrap on dict access
---+
 Reporter:  FunkyBob   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by d1ffuz0r):

 tested in Python 2.7, 3.3

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19407: queryset.none() acts like queryset.all() when using a values_list in a filter

[Django]

#19407: queryset.none() acts like queryset.all() when using a values_list in a
filter
-+-
 Reporter:  orblivion|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  1|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by ubercore):

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


Comment:

 Sorry, different problem, but this does appear to be fixed. Re-closing.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19844: Uniqueness validation of USERNAME_FIELD should be overridable.

[Django]

#19844: Uniqueness validation of USERNAME_FIELD should be overridable.
-+-
 Reporter:  josh@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.5-rc-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by claudep):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Design decision needed
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 We could turn the validation error in a mere warning. However, it should
 make clear that some part of `contrib.auth` will not function properly
 (for example `changepassword` management command, which uses
 `USERNAME_FIELD` as a key to retrieve user instances, or `ModelBackend`).
 I'll leave to Russell about the design decision.

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

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

Re: [Django] #7732: Oracle Backend with SessionPool

[Django]

#7732: Oracle Backend with SessionPool
-+-
 Reporter:  halturin |Owner:  mboersma
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  yandex-sprint|  Needs documentation:  1
  oracle session pool|  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-

Comment (by skyl):

 Unfortunately, I think there needs to be some error-checking on the
 connection after it is acquired from the pool. After some hours (I didn't
 configure the instance I'm running against so I'm not sure how long), I
 get `ORA-02399: exceeded maximum connect time, you are being logged off`;
 then, the pool continues to try to get the same connection, failing every
 time with, `ORA-01012: not logged on`. I think there are 2 options then.

 1) put a `CONN_MAX_AGE` parameter in the `SESSION_POOL` settings dict
 and drop the connection if it is close enough to that age
 2) ping the connection after it is acquired and drop it if it is not
 usable

 (1) Age is not an attribute of the connection that I can see; so, it would
 be ugly to do our own book-keeping on the age of the connections in the
 pools we are holding. This does not cover other possible error scenarios.
 (2) This would be a hit to performance every time a connection is
 acquired.

 I think (2) would be easy enough to add. Other 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17887: postgresql_psycopg2 sometimes leaves connections "idle in transaction"

[Django]

#17887: postgresql_psycopg2 sometimes leaves connections "idle in transaction"
-+-
 Reporter:  brodie   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  psycopg2 |  Needs documentation:  0
  transactions   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by aaugustin):

 > I think ideally, Django would by default issue a ROLLBACK after every
 request.

 https://github.com/django/django/pull/733 does that.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18135: Sleeping Database Connections on Startup with MySQL

[Django]

#18135: Sleeping Database Connections on Startup with MySQL
-+-
 Reporter:  Mnewman  |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  MySQL|  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mnewman):

 This is not scalable. It makes sense for small applications to have a
 database query open for every thread that you have running the Django app,
 but what happens as your application scales? You can leverage agressive
 caching techniques or NoSQL to make the load on the databases less and
 less. Some applications that I run only need connection to the database
 when a write operation is performed.

 So what happens on sites, like I have, that run millions of concurrents? I
 need hundreds of thousands threads to properly scale. I cannot afford a
 relational database that requires that many open "sleeping" connections.

 Persistant connections are a fine thing for small sites that don't
 autoscale along with swaths of users that are looking to improve
 performance by the couple of hundredths of second that it takes to connect
 to a local database, but when it comes to a large site, the overhead of a
 connection on each Django instance is really detrimental.

 This needs to at least be an option. The difference in price between a
 database that has 50 available connections to one that requires 500 is
 extreme. Applications can cache queries to the database, they can't
 magically increase the number of available connections to the database.

 I will weigh in on the discussion on django-dev, can you point me in the
 right direction? I have not seen it pass through my inbox.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18135: Sleeping Database Connections on Startup with MySQL

[Django]

#18135: Sleeping Database Connections on Startup with MySQL
-+-
 Reporter:  Mnewman  |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  MySQL|  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin
 * status:  new => assigned
 * component:  Uncategorized => Database layer (models, ORM)
 * stage:  Ready for checkin => Design decision needed


-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18135: Sleeping Database Connections on Startup with MySQL

[Django]

#18135: Sleeping Database Connections on Startup with MySQL
-+-
 Reporter:  Mnewman  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  MySQL| 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 aaugustin):

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


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

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

Re: [Django] #18135: Sleeping Database Connections on Startup with MySQL

[Django]

#18135: Sleeping Database Connections on Startup with MySQL
-+-
 Reporter:  Mnewman  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  MySQL| Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by aaugustin):

 Replying to [comment:2 Mnewman]:
 > Practical effect is that a database only has so many connections
 available. Each instance fires up a connection, so if a database has 50
 available connections and you have 10 servers with 5 instances each, you
 all of a sudden are out of database connections. Sleeping connections are
 a really bad thing.

 I stumbled upon this ticket while working on persistent database
 connections and I don't understand this argument.

 If you have 50 workers, and they're all serving requests simultaneously,
 then you're going to have 50 database connections in parallel anyway.

 If your database is only allows, say, 20 connections at a time, then you
 can't have more than 20 workers active, and there's no point in having 50
 of them!

 I fail to see how sleeping connections are a bad thing.

 

 Currently, the connection created at startup will be closed after the
 first query. In the near future, it will stay open. (See the discussion on
 django-developers.)

 I'm going to revert this change.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15119: MySQL backend generates unnecessary commands

[Django]

#15119: MySQL backend generates unnecessary commands
-+-
 Reporter:  lukesneeringer   |Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.2
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Currently the behavior for MySQL is inconsistent with all the other
 database backends. After 29628e0b6e5b1c6324e0c06cc56a49a5aa0747e0, fixing
 this ticket is as simple as removing the definition of `_valid_connection`
 in the MySQL database backend.

 Then, if we want to introduce resilience to database connection failures,
 we should do it consistently on all backends.

 Hardcoding retries doesn't sound like a good idea. For instance, if the
 connection breaks between two queries in a transaction, the database will
 roll back the first query; at this point, if Django automatically reopens
 a connection, retries the second query and commits the transaction, only
 the changes from the second query will be saved!

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15119: MySQL backend generates unnecessary commands

[Django]

#15119: MySQL backend generates unnecessary commands
-+-
 Reporter:  lukesneeringer   |Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.2
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 Also discussed here: https://groups.google.com/d/msg/django-
 developers/oIkjJbdWVEo/xOiZF3gP0t4J

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19844: Uniqueness validation of USERNAME_FIELD should be overridable.

[Django]

#19844: Uniqueness validation of USERNAME_FIELD should be overridable.
--+--
 Reporter:  josh@…|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.auth  |Version:  1.5-rc-1
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+--
 The resolution of #19822 by commit
 bc6746ac303ab625f2bc6fc878bd63661c784a59 introduces validation of the
 uniqueness of the specified USERNAME_FIELD in a way that cannot be
 (easily?) overridden. This is probably a good default behavior, however it
 breaks in any cases where you may not want unique usernames. The
 discussion on the original ticket clearly assumes that having non-unique
 usernames is an inherently bad design decision. This may very well be
 true, but, as I'm sure we're all aware, the exigencies of web development
 do not always allow us to restrict ourselves to good design decisions.

 As a specific example, I am working on a site that is required to
 integrate with a legacy system. The requirements for the project are such
 that it is necessary for us to preserve the user information from the
 legacy system faithfully. As such, this requires us to, among other
 things, allow the users to log in with nothing more than their email
 address and password (easily done), and allow for the possibility that
 multiple people will use the same email address while still needing to
 have unique user accounts (a pain, but not horribly difficult).

 The enforced design decision introduced by
 bc6746ac303ab625f2bc6fc878bd63661c784a59 unfortunately means that we
 either need to fork Django to keep that commit out of our codebase, hack
 around the validation by designating some field other than the email
 address our USERNAME_FIELD, or restrict ourselves to older code that does
 not have this restriction.

 It seems to me that a much better solution would be to not unnecessarily
 restrict the flexibility introduced by swappable user models, and make
 this the default, but still changeable, behavior.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19843: ORM generate dupes when filtering twice on related objects

[Django]

#19843: ORM generate dupes when filtering twice on related objects
--+
 Reporter:  tonnzor   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When I apply to a QuerySet a filter for related model twice -- I get
 dupes.

 Let's say we have classes:
 {{{
 from django.db import models

 class Film(models.Model):
 pass

 class Person(models.Model):
 pass

 class PersonInFilm(models.Model):
 film = models.ForeignKey(Film)
 person = models.ForeignKey(Person)
 title = models.CharField(max_length=50)
 }}}

 Then we try to find out needed PersonInFilm -- multiple filters (e.g.
 using Managers):
 {{{
 qs_wrong =
 Person.objects.filter(personinfilm__film=1).filter(personinfilm__role=1)
 print "%s rows\n%s" % (qs_wrong.count(), qs_wrong.values('id').query)
 }}}
 This will result in:
 {{{
 15 rows
 SELECT `persons_person`.`id` FROM `persons_person`
 INNER JOIN `persons_personinfilm` ON (`persons_person`.`id` =
 `persons_personinfilm`.`person_id`)
 INNER JOIN `persons_personinfilm` T4 ON (`persons_person`.`id` =
 T4.`person_id`)
 WHERE (`persons_personinfilm`.`film_id` = 1  AND T4.`role_id` = 1 )
 }}}

 Then we try to find out needed PersonInFilm -- single filter:
 {{{
 qs_correct = Person.objects.filter(personinfilm__film=1,
 personinfilm__role=1)
 print "%s rows\n%s" % (qs_correct.count(), qs_correct.values('id').query)
 }}}
 This will result in:
 {{{
 1 rows
 SELECT `persons_person`.`id` FROM `persons_person`
 INNER JOIN `persons_personinfilm` ON (`persons_person`.`id` =
 `persons_personinfilm`.`person_id`)
 WHERE (`persons_personinfilm`.`role_id` = 1  AND
 `persons_personinfilm`.`film_id` = 1 )
 }}}

 Please keep in mind that often it is impossible to put filter in one
 command -- e.g. when you use custom Manager.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19407: queryset.none() acts like queryset.all() when using a values_list in a filter

[Django]

#19407: queryset.none() acts like queryset.all() when using a values_list in a
filter
-+-
 Reporter:  orblivion|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ubercore):

 * status:  closed => new
 * resolution:  duplicate =>
 * needs_tests:  0 => 1


Comment:

 This actually isn't, afaict, a dupe of #17712. The key to this issue is
 using __in with a ValuesListQuerySet, when the ValuesListQuerySet
 evaluates to an empty list. The WHERE clause is updated with the subquery,
 but the subquery itself doesn't get a WHERE clause, so it returns all
 rows:


 {{{
 WHERE "table_name"."lookup_field" IN (SELECT U0."lookup_field" FROM
 "other_table" U0)
 }}}

 The expected behavior would be:

 {{{
 WHERE "table_name"."lookup_field" IN (SELECT U0."lookup_field" FROM
 "other_table" U0 where "lookup_field" = 'lookup_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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19842: annotate()-based solution to distinct and order_by problem

[Django]

#19842: annotate()-based solution to distinct and order_by problem
--+
 Reporter:  jogwen|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 
https://docs.djangoproject.com/en/1.4/ref/models/querysets/#django.db.models.query.QuerySet.distinct

 Note about how distinct may not work when ordering by related model fields
 could point the reader at this solution
 http://archlinux.me/dusty/2010/12/07/django-dont-use-distinct-and-
 order_by-across-relations/, using annotate().

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 29628e: Factored out common code in database backends.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 29628e0b6e5b1c6324e0c06cc56a49a5aa0747e0
  
https://github.com/django/django/commit/29628e0b6e5b1c6324e0c06cc56a49a5aa0747e0
  Author: Aymeric Augustin 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
M django/db/backends/__init__.py
M django/db/backends/mysql/base.py
M django/db/backends/oracle/base.py
M django/db/backends/postgresql_psycopg2/base.py
M django/db/backends/sqlite3/base.py

  Log Message:
  ---
  Factored out common code in database backends.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19837: Regression in QuerySet.exclude and many to many

[Django]

#19837: Regression in QuerySet.exclude and many to many
-+-
 Reporter:  timo |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timo):

 The patch fixes the issue in the app I discovered this in.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19456: SimpleLazyObject raises RuntimeError if __class__ accessed while tracing execution

[Django]

#19456: SimpleLazyObject raises RuntimeError if __class__  accessed while 
tracing
execution
-+-
 Reporter:  rouyrre+django@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by anonymous):

 Code was updated as discussed with @spookylukey
 
https://github.com/blaze33/django/commit/2f6d887bd0a110e3a662ac1d056d6cdabf38632b

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19717: Inconsistent documentation: refers to a "root QuerySet", which is really a Manager instance.

[Django]

#19717: Inconsistent documentation: refers to a "root QuerySet", which is 
really a
Manager instance.
-+-
 Reporter:   |Owner:  nobody
  julien.aubert.mail@…   |   Status:  closed
 Type:   |  Version:
  Cleanup/optimization   |  1.5-beta-1
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by Tim Graham ):

 In [changeset:"5d853db90e71691f2b6b0827b002b9d0edb38fd1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5d853db90e71691f2b6b0827b002b9d0edb38fd1"
 [1.5.X] Fixed #19717 - Removed mentions of "root QuerySet" in docs.

 Thanks julien.aubert.mail@ for the report and James Pic for the patch.

 Backport of 64d0f89ab1 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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 5d853d: [1.5.X] Fixed #19717 - Removed mentions of "root Q...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 5d853db90e71691f2b6b0827b002b9d0edb38fd1
  
https://github.com/django/django/commit/5d853db90e71691f2b6b0827b002b9d0edb38fd1
  Author: Tim Graham 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
M docs/topics/db/queries.txt

  Log Message:
  ---
  [1.5.X] Fixed #19717 - Removed mentions of "root QuerySet" in docs.

Thanks julien.aubert.mail@ for the report and James Pic for the patch.

Backport of 64d0f89ab1 from master



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 64d0f8: Fixed #19717 - Removed mentions of "root QuerySet"...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 64d0f89ab1dc6ef8a84814f567050fc063d67de2
  
https://github.com/django/django/commit/64d0f89ab1dc6ef8a84814f567050fc063d67de2
  Author: Tim Graham 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
M docs/topics/db/queries.txt

  Log Message:
  ---
  Fixed #19717 - Removed mentions of "root QuerySet" in docs.

Thanks julien.aubert.mail@ for the report and James Pic for the patch.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19717: Inconsistent documentation: refers to a "root QuerySet", which is really a Manager instance.

[Django]

#19717: Inconsistent documentation: refers to a "root QuerySet", which is 
really a
Manager instance.
-+-
 Reporter:   |Owner:  nobody
  julien.aubert.mail@…   |   Status:  closed
 Type:   |  Version:
  Cleanup/optimization   |  1.5-beta-1
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"64d0f89ab1dc6ef8a84814f567050fc063d67de2"]:
 {{{
 #!CommitTicketReference repository=""
 revision="64d0f89ab1dc6ef8a84814f567050fc063d67de2"
 Fixed #19717 - Removed mentions of "root QuerySet" in docs.

 Thanks julien.aubert.mail@ for the report and James Pic for the patch.
 }}}

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

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

[django/django] 92837a: Avoided firing the request_finished signal in test...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 92837ae56999a6f602d22130bfb3c49cd9b40242
  
https://github.com/django/django/commit/92837ae56999a6f602d22130bfb3c49cd9b40242
  Author: Aymeric Augustin 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
M tests/regressiontests/httpwrappers/tests.py
M tests/regressiontests/serializers_regress/tests.py
M tests/regressiontests/views/tests/static.py

  Log Message:
  ---
  Avoided firing the request_finished signal in tests.

* Avoided calling BaseHttpResponse.close(). The test client take care of
  that since acc5396e.
* Disconnected the request_finished signal when this method must be
  called. The test client has a similar implementation since bacb097a.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #7732: Oracle Backend with SessionPool

[Django]

#7732: Oracle Backend with SessionPool
-+-
 Reporter:  halturin |Owner:  mboersma
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  yandex-sprint|  Needs documentation:  1
  oracle session pool|  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-

Comment (by erny):

 I had the following problems in the past: The Oracle pools is a "per
 process" pool. Each Python Process gets its own pool. Supposing X
 processes (apache prefork, wsgi, etc.) with each Y min connections we get
 X * Y connections. So keep your min connections count low. With Oracle 11,
 there seems to be a server side session pool which should be much more
 convenient, but I didn't test it.

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

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

Re: [Django] #19841: Problem in documentation "Writing your first Django app, part 1" with manage.py runserver

[Django]

#19841: Problem in documentation "Writing your first Django app, part 1" with
manage.py runserver
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  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 aaugustin):

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


Comment:

 This is a problem with your installation of Django.

 How did you install it?

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

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

[Django] #19841: Problem in documentation "Writing your first Django app, part 1" with manage.py runserver

[Django]

#19841: Problem in documentation "Writing your first Django app, part 1" with
manage.py runserver
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The documentation at
 https://docs.djangoproject.com/en/1.4/intro/tutorial01/ "Writing your
 first Django app, part 1" explains how to start the development server
 using
 {{{python manage.py runserver}}}
 However on systems where python3 is the default python interpreter, one
 gets an error like the following:

 {{{
 # python manage.py runserver
 Traceback (most recent call last):
   File "manage.py", line 8, in 
 from django.core.management import execute_from_command_line
 ImportError: No module named 'django'
 }}}

 It works fine if one runs
 {{{python2 manage.py runserver}}}

 Now to avoid confusion, since it is not always clear on the first sight,
 what interpreter runs and since the documentation gives no hint about,
 that you have to run manage.py with python2, it would be better if it told
 the new user to run the script itself, since the shebang line states the
 correct interpreter already.
 Therefore the documentation could be canged to
 {{{
 chmod +x manage.py
 ./manage.py runserver
 }}}
 and everything should work as expected without python2/3 confusion.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17508: DateDetailView should accept less specific dates, ie Year/Month or just Year

[Django]

#17508: DateDetailView should accept less specific dates, ie Year/Month or just
Year
---+
 Reporter:  AndrewIngram   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Generic views  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by hirokiky):

 * cc: hirokiky@… (added)
 * needs_docs:  0 => 1
 * has_patch:  0 => 1
 * version:  1.3 => master
 * needs_tests:  0 => 1


Comment:

 I added a patch.

 Now, DateDetail takes a attribute to set the unity of dates named
 '''date_separate_unit'''.
 The attribute allows a vaule, which '''daily''', '''monthly''' or
 '''yearly''':
 * daily: /2012/jan/06/blog-entry-name/
 * monthly: /2012/jan/blog-entry-name/
 * yearly: /2012/blog-entry-name/
 How do you feel about this behavior and implementation?
 I think it is better to hear someone's opinion.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 09ca01: Removed an unecessary function.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 09ca0107689c6219ba311be58134407e49125235
  
https://github.com/django/django/commit/09ca0107689c6219ba311be58134407e49125235
  Author: Aymeric Augustin 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
M django/db/backends/sqlite3/base.py

  Log Message:
  ---
  Removed an unecessary function.

It was introduced by the refactoring in 5a4e63e6 and made redundant by
the refactoring in 18934677.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18447: LazyObject doesn't unwrap on dict access

[Django]

#18447: LazyObject doesn't unwrap on dict access
---+
 Reporter:  FunkyBob   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by fhahn):

 * cc: flo@… (added)
 * needs_tests:  1 => 0


Comment:

 I think putting the test and the patch into one file would make applying
 the patch a tiny bit easier.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Django]

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

 * cc: vlastimil.zima@… (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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19839: test is dependent on settings.py ordering: contrib.auth.tests.forms.PasswordResetFormTest.test_custom_email_subject

[Django]

#19839: test is dependent on settings.py ordering:
contrib.auth.tests.forms.PasswordResetFormTest.test_custom_email_subject
--+
 Reporter:  limscoder |Owner:  claudep
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"5ec0405a09c4b05b7ee6c58bf52a06290143d788"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5ec0405a09c4b05b7ee6c58bf52a06290143d788"
 Fixed #19839 -- Isolated auth tests from customized TEMPLATE_LOADERS

 Thanks limscoder for the report.
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 5ec040: Fixed #19839 -- Isolated auth tests from customize...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 5ec0405a09c4b05b7ee6c58bf52a06290143d788
  
https://github.com/django/django/commit/5ec0405a09c4b05b7ee6c58bf52a06290143d788
  Author: Claude Paroz 
  Date:   2013-02-18 (Mon, 18 Feb 2013)

  Changed paths:
M django/contrib/auth/tests/context_processors.py
M django/contrib/auth/tests/forms.py

  Log Message:
  ---
  Fixed #19839 -- Isolated auth tests from customized TEMPLATE_LOADERS

Thanks limscoder for the report.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19839: test is dependent on settings.py ordering: contrib.auth.tests.forms.PasswordResetFormTest.test_custom_email_subject

[Django]

#19839: test is dependent on settings.py ordering:
contrib.auth.tests.forms.PasswordResetFormTest.test_custom_email_subject
--+
 Reporter:  limscoder |Owner:  claudep
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.4
 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):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19840: Traceback view: href to version control page

[Django]

#19840: Traceback view: href to version control page
---+
 Reporter:  guettli|  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:  debug_view
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 It would be very good if the traceback view (in DEBUG mode) would create
 links
 to the version control page:

 Example traceback:
 {{{

 /home/modwork_egs_dt/djangotools/utils/formutils.py in form2str
 rows.append(formdict.field(field, td_add=td_add.get(field,
 '')))
 /home/modwork_egs_dt/djangotools/utils/formutils.py in field
 widget_str=bf.as_widget(bf.field.widget, attrs=attrs)
 /home/modwork_egs_dt/django/forms/forms.py in as_widget

 }}}
 The file name of the python file should be a link to the version control.
 Of course this can only be done after
 telling django where each app has its web repository.

 In the above example "djangotools" is an app which is hosted in our
 company at http://foo.lan/viewvc/djangotools/
 The debug page would need to create a link like this
 http://foo.lan/viewvc/djangotools/trunk/utils/formutils.py

 I don't know how to implement it. But it would be a nice feature for
 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.
For more options, visit https://groups.google.com/groups/opt_out.