[Django] #28012: JsonField PostgreSQL problem

2017-04-02 Thread Django
#28012: JsonField PostgreSQL problem
+
   Reporter:  Martín Peveri |  Owner:  (none)
   Type:  Uncategorized | Status:  new
  Component:  contrib.postgres  |Version:  1.10
   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 |
+
 Hi, I have a model with a field JsonField of PostgreSQL of name 'data',
 like this:

 {{{
 class ItemCampaign(models.Model):

campaign = models.ForeignKey(
Campaign, related_name="itemscampaign", verbose_name="Item campaña"
)
data = JSONField(default=dict)

def __str__(self):
return self.campaign.name
 }}}


 In this field i have one record with this data, for example:

 {{{
 [{'number': '1160188479', 'id': 0, 'content': 'hello', 'processed': True},
 {'number': '1160188479', 'id': 1, 'content': 'hello', 'processed': False},
 {'number': '1160188479', 'id': 2, 'content': 'hello', 'processed': False},
 {'number': '1162341721', 'id': 3, 'content': 'hello', 'processed': False},
 {'number': '1162341721', 'id': 4, 'content': 'hello', 'processed': False},
 {'number': '1162341721', 'id': 5, 'content': 'hello', 'processed': False}]
 }}}

 If i want filtered, like this:

 {{{
 itemscampaign.filter(data__contains=[{'processed': True}])
 }}}

 This code returned all content data field, Instead of just the dict with
 'processed' in True. I want know if this is an error or not is possible.

 Thanks!

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

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


[Django] #28011: Correct Field.hidden docs regarding what fields are hidden

2017-04-02 Thread Django
#28011: Correct Field.hidden docs regarding what fields are hidden
-+
   Reporter:  Tim Graham |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Documentation  |Version:  1.10
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 The
 
[https://github.com/django/django/blob/d4d79d0f200357b28419203557cc61c8168316ab/docs/ref/models/fields.txt#L1912-L1918
 Field.hidden] docs say, "Boolean flag that indicates if a field is used to
 back another non-hidden field’s functionality (e.g. the content_type and
 object_id fields that make up a GenericForeignKey)." This seems
 inaccurate:
 {{{#!python
 from django.contrib.contenttypes.fields import GenericForeignKey,
 GenericRelation
 from django.contrib.contenttypes.models import ContentType
 from django.db import models

 class TaggedItem(models.Model):
 tag = models.SlugField()
 content_type = models.ForeignKey(ContentType,
 on_delete=models.CASCADE, related_name='tagged_items')
 object_id = models.PositiveIntegerField()
 content_object = GenericForeignKey('content_type', 'object_id')

 >>> TaggedItem._meta.get_field('object_id')
 
 >>> TaggedItem._meta.get_field('content_type')
 
 }}}
 (`object_id` and `content_type` aren't hidden).

 There's a related discussion in the
 
[https://github.com/django/django/blob/d4d79d0f200357b28419203557cc61c8168316ab/docs/ref/models/meta.txt#L79-L84
 Options.get_fields() docs] that also needs some correction.

 Another thing I noticed is that `Field.hidden` is
 
[https://github.com/django/django/blob/d4d79d0f200357b28419203557cc61c8168316ab/django/db/models/options.py#L792-L793
 only consulted for relational fields]. Removing `Field.hidden` and
 `GenericForeignKey.hidden` doesn't result in any crash of `get_fields()`
 because those attributes are never consulted.

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

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


Re: [Django] #27974: Degraded performance when rendering ChoiceField with lots of options and DEBUG=True

2017-04-02 Thread Django
#27974: Degraded performance when rendering ChoiceField with lots of options and
DEBUG=True
-+-
 Reporter:  karyon   |Owner:  kapil
 Type:   |  garg
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  1.11
 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 Tim Graham):

 * needs_tests:  1 => 0


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

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


Re: [Django] #27025: Python 3.6 compatibility

2017-04-02 Thread Django
#27025: Python 3.6 compatibility
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 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
--+

Comment (by Tim Graham ):

 In [changeset:"e34cce79ff667876bf55ea41395f15f0d2534a40" e34cce79]:
 {{{
 #!CommitTicketReference repository=""
 revision="e34cce79ff667876bf55ea41395f15f0d2534a40"
 [1.11.x] Refs #27025 -- Fixed "invalid escape sequence" warning in
 auth_tests on Python 3.6.

 Backport of d4d79d0f200357b28419203557cc61c8168316ab from master
 }}}

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

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


Re: [Django] #27025: Python 3.6 compatibility

2017-04-02 Thread Django
#27025: Python 3.6 compatibility
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 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
--+

Comment (by Tim Graham ):

 In [changeset:"d4d79d0f200357b28419203557cc61c8168316ab" d4d79d0f]:
 {{{
 #!CommitTicketReference repository=""
 revision="d4d79d0f200357b28419203557cc61c8168316ab"
 Refs #27025 -- Fixed "invalid escape sequence" warning in auth_tests on
 Python 3.6.
 }}}

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

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


Re: [Django] #28005: normalize usage of terms 'argument' and 'parameter'

2017-04-02 Thread Django
#28005: normalize usage of terms 'argument' and 'parameter'
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Damir
 Type:   |  Rakhimov
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Damir Rakhimov):

 * owner:  nobody => Damir Rakhimov
 * status:  new => assigned


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

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


Re: [Django] #18394: Add warning for invalid JavaScriptCatalog 'packages'

2017-04-02 Thread Django
#18394: Add warning for invalid JavaScriptCatalog 'packages'
--+
 Reporter:  James Bennett |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Internationalization  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Claude Paroz):

 Aymeric, would you like to develop about your backwards compatibility
 concerns?
 Would erroring out be acceptable (considering a release note about that
 new behavior)?

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

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


Re: [Django] #26788: update of geometry field from the another one crashes

2017-04-02 Thread Django
#26788: update of geometry field from the another one crashes
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Accepted => Ready for checkin


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

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


Re: [Django] #27573: Distance function returns Distance object instead of raw value on MySQL

2017-04-02 Thread Django
#27573: Distance function returns Distance object instead of raw value on MySQL
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"898e623db0fa6b2cf0b187a3db78b675cde111cf" 898e623]:
 {{{
 #!CommitTicketReference repository=""
 revision="898e623db0fa6b2cf0b187a3db78b675cde111cf"
 Fixed #27573 -- Made Distance on geodetic coordinates return a raw value
 on MySQL.
 }}}

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

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


Re: [Django] #27928: Avoid SET/DROP DEFAULT unless a field changes from null to non-null

2017-04-02 Thread Django
#27928: Avoid SET/DROP DEFAULT unless a field changes from null to non-null
-+-
 Reporter:  Christophe Pettus|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette ):

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


Comment:

 In [changeset:"35c0025151ad411e691a2fa62a0dd3507ebafd82" 35c0025]:
 {{{
 #!CommitTicketReference repository=""
 revision="35c0025151ad411e691a2fa62a0dd3507ebafd82"
 Fixed #27928 -- Avoided SET/DROP DEFAULT unless a field changes from null
 to non-null.

 Thanks Christophe Pettus, Matteo Pietro Russo for reports and Tim for
 review.
 }}}

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

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


Re: [Django] #56: Primary key columns should be UNSIGNED

2017-04-02 Thread Django
#56: Primary key columns should be UNSIGNED
-+-
 Reporter:  Manuzhai |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Re: [Django] #27928: Avoid SET/DROP DEFAULT unless a field changes from null to non-null

2017-04-02 Thread Django
#27928: Avoid SET/DROP DEFAULT unless a field changes from null to non-null
-+-
 Reporter:  Christophe Pettus|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Accepted => Ready for checkin


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

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


Re: [Django] #27923: Add form signals (pre_init, post_init, pre_clean, post_clean, etc.)

2017-04-02 Thread Django
#27923: Add form signals (pre_init, post_init, pre_clean, post_clean, etc.)
+-
 Reporter:  David   |Owner:  luojiebin
 Type:  New feature |   Status:  assigned
Component:  Forms   |  Version:
 Severity:  Normal  |   Resolution:
 Keywords:  forms, signals  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+-
Changes (by Tim Graham):

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


Re: [Django] #18394: Add warning for invalid JavaScriptCatalog 'packages'

2017-04-02 Thread Django
#18394: Add warning for invalid JavaScriptCatalog 'packages'
--+
 Reporter:  James Bennett |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Internationalization  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham):

 Instead of a `RuntimeWarning` as proposed in the PR, would it make more
 sense to raise a deprecation warning and eventually error out (or even
 error out now)? I usually favor raising an error straight away, rather
 than delaying that notice with a deprecation path, if it reveals a mistake
 a developer made (a past case was `QuerySet.select_related()` validating
 the values it receives) but I'll defer a decision here since I'm not a
 `JavaScriptCatalog` user.

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


Re: [Django] #18394: Add warning for invalid JavaScriptCatalog 'packages'

2017-04-02 Thread Django
#18394: Add warning for invalid JavaScriptCatalog 'packages'
--+
 Reporter:  James Bennett |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Internationalization  |  Version:  1.4
 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 Claude Paroz):

 * has_patch:  0 => 1


Comment:

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

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

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


Re: [Django] #11854: Add support of PostGIS's Azimuth function

2017-04-02 Thread Django
#11854: Add support of PostGIS's Azimuth function
-+-
 Reporter:  Christian Karrié |Owner:  Sergey
 |  Fedoseev
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  azimuth, postgis | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"5e710cf4a5dba1fc30e3b6775b83c2218e57cd36" 5e710cf4]:
 {{{
 #!CommitTicketReference repository=""
 revision="5e710cf4a5dba1fc30e3b6775b83c2218e57cd36"
 Fixed #11854 -- Added Azimuth GIS function. (#8286)
 }}}

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


Re: [Django] #28010: select_for_update() is too eager in presence of joins

2017-04-02 Thread Django
#28010: select_for_update() is too eager in presence of joins
-+-
 Reporter:  Ran Benita   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Simon Charette):

 * version:  1.10 => master
 * stage:  Unreviewed => Accepted


Comment:

 Allowing the usage of `FOR UPDATE OF` is definitely something we want to
 add.

 Now for the proposed options the one that makes the most sense to me is
 `1.`. `2.` would be backward incompatible given we actually lock all rows
 by default and some backends don't allow locking only a specific table
 which would make `select_for_update()` behave quite a bit differently on
 different backends.

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

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


Re: [Django] #28009: Document and test Field.empty_value for CharField subclasses (was: Changes to models.CharField and forms.CharField impact subclasses as well)

2017-04-02 Thread Django
#28009: Document and test Field.empty_value for CharField subclasses
-+-
 Reporter:  Matt Braymer-Hayes   |Owner:  Matt
 Type:   |  Braymer-Hayes
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 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 Tim Graham):

 * stage:  Unreviewed => Accepted


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

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


[Django] #28010: select_for_update() is too eager in presence of joins

2017-04-02 Thread Django
#28010: select_for_update() is too eager in presence of joins
-+-
   Reporter:  Ran|  Owner:  nobody
  Benita |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  1.10
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Using `select_for_update()` on a queryset appends ` FOR UPDATE` to the
 query. If the query joins other tables, the effect is that all tables are
 locked. I believe this is not what most people using `select_for_update()`
 want, instead they only want to lock the row from the main table.

 == Example

 Consider a scenario like this:

 {{{#!python
 class Product(models.Model):
 name = models.CharField(max_length=100)
 price = models.PositiveIntegerField()


 class Order(models.Model):
 product = models.ForeignKey(Product, on_delete=models.PROTECT)
 status = models.CharField(max_length=100, choices=(
 ('NEW', 'New'),
 ('APPROVED', 'Approved'),
 ('CANCELED', 'Canceled'),
 )

 ...

 @classmethod
 def approve(cls, id):
 with transaction.atomic():
 order =
 Order.objects.select_related('product').select_for_update().get(pk=id)
 # ...Check order.product.price & stuff...
 order.status = 'APPROVED'
 order.save()

 @classmethod
 def cancel(cls, id):
 with transaction.atomic():
 # Similar...
 }}}

 Here, locking is needed in order to serialize `approve()` and `cancel()`
 on the same Order, to avoid race conditions.

 I have also used `select_related` in `approve()`, in order to avoid an
 extra query. Potentially, there are many related objects, but to keep the
 example simple I added just one.

 The interaction between `select_related` and `select_for_update` has the
 unintended consequence (IMO) of also locking the related `Product` row.
 Hence, if there is some concurrent task which updates product prices for
 example, it can cause conflicts, slowdowns, deadlocks, and other bad
 things.

 The fix is to remove the `select_related`. But then extra queries are
 needed for each related object access without a reasonable workaround (I
 think?).

 == Possible solutions

 PostgreSQL (which I am using) has an option to specify exactly which
 tables are to be locked, instead of locking all tables in the query:
 https://www.postgresql.org/docs/9.6/static/sql-select.html#SQL-FOR-UPDATE-
 SHARE. The syntax is `SELECT ... FOR UPDATE OF orders_order`.

 Oracle also supports this with similar syntax, however it allows
 specifying which *columns* to lock:
 http://docs.oracle.com/javadb/10.8.3.0/ref/rrefsqlj31783.html. I guess
 there it is possible to lock specific columns of specific rows, while
 postgres only locks full rows.

 I am not familiar with MySQL but it doesn't seem like it supports refining
 the `FOR UPDATE`.

 Here are some possible solutions I can think of:

 1. Add support for `select_for_update` to specify which models to lock,
 e.g. `select_for_update('self', 'product')`. This will use the `OF`
 syntax.

 2. Only support the `select_for_update('self')` behavior, and make it
 implicit, i.e. `select_for_update` only ever locks the main model of the
 QuerySet.

 3. Add a way to do `select_related` on an already-existing object,
 something like a standalone `select_related_objects` after the existing
 `prefetch_related_objects` function:
 https://docs.djangoproject.com/en/1.10/ref/models/querysets/#prefetch-
 related-objects, and keep `select_for_update` as-is. Then it should at
 least be possible to do one extra query instead of one per related object.

 Thanks for reading this far :)

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


Re: [Django] #24317: Deprecate field.rel, replace it with real field instances

2017-04-02 Thread Django
#24317: Deprecate field.rel, replace it with real field instances
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Asif Saifuddin Auvi):

 Replying to [comment:17 Gabriel Canto de Souza]:
 > I also had a huge difficulty sorting out the fields of
 ._meta.get_fields() , what I was trying to achieve was get ONLY the
 reverse fields (because in our context every relationship is
 bidirectional, and everything is generic/auto generated)
 >
 > This gets really complicated with m2m that contain through tables,
 because not only you get the reverse m2m remote_field, but also the m2o
 relationship with the through table, so no only you have to figure out
 these are reverse, but group both the m2m and m2o that revert to the same
 relationship.
 >
 > This is the code I managed to come up with to get only the reverse rels:
 >
 >
 >   {{{#!python
 >
 >  #I'm sure there's a better way of doing this
 >  #This is the documented way of getting reverse fields, but it also gets
 ManyToOne rel with the through table of forward m2m rels, so we have to
 filter them
 >  reverse_fields = [f for f in opts.get_fields() if f.auto_created and
 not f.concrete]
 >  reverse_m2m = [f for f in reverse_fields if f.__class__.__name__ ==
 'ManyToManyRel' and f.on_delete == None and not
 getattr(model,f.field.name,False)]
 >  #Also filtering the ManyToOne rel with the through table of the reverse
 m2m rels, because we need to differentiate them from reverse ManyToOne
 with other models(not through)
 >  reverse_m2m_through = [f for f in reverse_fields if
 f.__class__.__name__ == 'ManyToOneRel'  and f.related_model in [f.through
 for f in reverse_m2m if getattr(f,'through',False)]]
 >  forward_m2m = [f.remote_field for f in opts.get_fields() if not
 f.auto_created and f.many_to_many]
 >  #Filtering the ManyToOne rels with the through table of forwards m2m
 rels, same logic as above
 >  forward_m2m_through = [f for f in reverse_fields if
 f.__class__.__name__ == 'ManyToOneRel'  and f.related_model in [f.through
 for f in forward_m2m if getattr(f,'through',False)]]
 >  reverse_fields_final = itertools.chain(reverse_m2m, [f for f in
 reverse_fields if f not in itertools.chain(reverse_m2m,
 reverse_m2m_through, forward_m2m, forward_m2m_through)])
 >   }}}
 >
 > I propose to add a new attribute ''is_reverse = True/False'' to
 facilitate this, of course this solution works in my context point of
 view, there might be a better approach to this
 >

 I am preparing a Draft DEP for addressing ORM relations API related issues
 here https://github.com/django/deps/pull/39

 It's still work in progress but you certainly add your thoughts/feedbacks.

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


Re: [Django] #27573: Distance function returns Distance object instead of raw value on MySQL

2017-04-02 Thread Django
#27573: Distance function returns Distance object instead of raw value on MySQL
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.9
 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 Sergey Fedoseev):

 * has_patch:  0 => 1


Comment:

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

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

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


Re: [Django] #26788: update of geometry field from the another one crashes

2017-04-02 Thread Django
#26788: update of geometry field from the another one crashes
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.9
 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 Sergey Fedoseev):

 * needs_better_patch:  1 => 0


Comment:

 These failures are fixed now.

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

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


Re: [Django] #11854: Add support of PostGIS's Azimuth function

2017-04-02 Thread Django
#11854: Add support of PostGIS's Azimuth function
-+-
 Reporter:  Christian Karrié |Owner:  Sergey
 |  Fedoseev
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  azimuth, postgis | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sergey Fedoseev):

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


Comment:

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

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

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


Re: [Django] #28008: Remove getElementsByClassName() function in technical 500 template

2017-04-02 Thread Django
#28008: Remove getElementsByClassName() function in technical 500 template
--+
 Reporter:  Tim Graham|Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Error reporting   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by kapil garg):

 I can work on this.

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


Re: [Django] #26608: Add a window function expression

2017-04-02 Thread Django
#26608: Add a window function expression
-+-
 Reporter:  Jamie Cockburn   |Owner:  Mads
 |  Jensen
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Josh Smeaton):

 * cc: josh.smeaton2 (removed)
 * cc: josh.smeaton@… (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/064.92bfe7d43e573ef47b191209ceb990c4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.