Re: [Django] #19914: MemcachedCacheTests failing on pylibmc

[Django]

#19914: MemcachedCacheTests failing on pylibmc
-+-
 Reporter:  bpeschier|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Cache system)  |  Version:  master
 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 edmorley):

 So I've dug into this a bit more, there are actually two tests that are
 broken under pylibmc, and the above only covers the first.

 == Issues with test_invalid_keys:

 This test tries to set two different types of invalid keys:
   1. a key that contains space characters
   2. another that exceeds the max allowed length

 Both python-memcached and pylibmc handle (2) fine. However (1) is
 problematic with pylibmc, since it causes subsequent requests to the
 server (ie teardown and later tests in the suite) to fail for the next few
 seconds.

 The cause of this is roughly:
   * python-memcached validates key names before sending, whereas by
 pylibmc doesn't by default (or more precisely, libmemcached doesn't by
 default)
   * therefore for pylibmc the invalid key name gets sent to the server,
 rather than being rejected client-side
   * this appears to expose some memcached server/libmemcache bug that
 isn't pylibmc's fault (though I'm hoping for clarification, see:
 https://github.com/lericson/pylibmc/issues/114#issuecomment-242929115)

 Possible workarounds are:
   a. not set keys names containing spaces (ie skip the test)
   b. enable pylibmc's client side key validation passing `verify_keys`
 within `behaviors` (just for this specific test)
   c. use the binary protocol (since it's not affected)

 In addition, since the bug only affects half of `test_invalid_keys()`, we
 could split the test in two, to reduce the amount we skip/test in a non-
 standard configuration.

 Note: The issue presents itself in two forms depending on
 libmemcached/memcached server versions. On Ubuntu 14.04 an assertion
 occurs in libmemcached, which causes the whole test run to abort (example
 in comment 2 above). Whereas on Ubuntu 16.04 a handful of exceptions are
 seen and the rest of the tests complete fine. I'm pretty sure the
 assertion *is* something pylibmc should be handling better, for which I've
 filed:
 https://github.com/lericson/pylibmc/issues/218
 (though even with that fixed, the underlying ~server bug still needs to be
 worked around)


 == Issues with test_memcached_deletes_key_on_failed_set:

 With the problematic test above skipped, the one remaining failure under
 pylibmc is:
 {{{
 ERROR: test_memcached_deletes_key_on_failed_set
 (cache.tests.MemcachedCacheTests)
 --
 Traceback (most recent call last):
   File "/home/vagrant/src/_todo/django/tests/cache/tests.py", line 1233,
 in test_memcached_deletes_key_on_failed_set
 cache.set('small_value', large_value)
   File
 "/home/vagrant/src/_todo/django/django/core/cache/backends/memcached.py",
 line 83, in set
 if not self._cache.set(key, value, self.get_backend_timeout(timeout)):
 Error: error 37 from memcached_set: SUCCESS
 }}}

 This is due to difference in behaviour between clients when the *value* is
 too long.

 Compare:
 * When the *key* is too long:
   - python-memcached: `memcache.MemcachedKeyLengthError: Key length is >
 250`
   - pylibmc: `ValueError: key length 251 too long, max is 250`
 * When the *value* is too long:
   - python-memcached: Returns successfully but didn't set the key-value
 (this is [https://github.com/linsomniac/python-memcached/issues/32 by
 design])
   - pylibmc 1.5.1: `pylibmc.Error: error 37 from memcached_set: SUCCESS`
   - pylibmc master: `pylibmc.TooBig`

 Possible options:
   a. just add a try-except around the `.set()` for both python-memcached
 and pylibmc
   b. differentiate between the two, and only expect exceptions for the
 pylibmc case (either by just catching them, or by enforcing using
 `assertRaises`)

--
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 

Re: [Django] #26539: Using Annotation As Update Parameter Generates Invalid SQL

[Django]

#26539: Using Annotation As Update Parameter Generates Invalid SQL
-+-
 Reporter:  dsanders11   |Owner:  PREM1980
 Type:  Bug  |   Status:  assigned
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 PREM1980):

 Need more clarifications on this.

 SQLLite and Mysql both passes the test. The queries generated are
 different(sqllite has SUBSELECT) but the result of the subselect is same
 as MYSQL.

 Here are the 2 queries thats generated. In MYSQL the select statement is
 generated first and then the results are applied to the update but in
 sqllite is select statement is applied directly as a subselect.

 MYSQL results:-

 >>>
 
Foo.objects.annotate(bname=F('related_bar__name')).update(bar_name=F('bar_name'))
 SELECT `polls_foo`.`id`
 FROM `polls_foo`
 INNER JOIN `polls_bar` ON (`polls_foo`.`related_bar_id` =
 `polls_bar`.`id`) [3.62ms]
 UPDATE `polls_foo`
 SET `bar_name` = `polls_foo`.`bar_name`
 WHERE `polls_foo`.`id` IN (6,7)

 SQLLite:-


 >>> Foo.objects.annotate(bname=F('related_bar__name'))
 SELECT "polls_foo"."id",
"polls_foo"."related_bar_id",
"polls_foo"."bar_name",
"polls_bar"."name" AS "bname"
 FROM "polls_foo"
 INNER JOIN "polls_bar" ON ("polls_foo"."related_bar_id" =
 "polls_bar"."id") LIMIT 21 [0.21ms]
 , ]>
 >>>
 
Foo.objects.annotate(bname=F('related_bar__name')).update(bar_name=F('bar_name'))
 BEGIN [0.03ms]
 UPDATE "polls_foo"
 SET "bar_name" = "polls_foo"."bar_name"
 WHERE "polls_foo"."id" IN
 (SELECT U0."id" AS Col1
  FROM "polls_foo" U0
  INNER JOIN "polls_bar" U1 ON (U0."related_bar_id" = U1."id"))
 [0.29ms]
 #7) [0.22ms]

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

Re: [Django] #10060: Multiple table annotation failure

[Django]

#10060: Multiple table annotation failure
-+-
 Reporter:  svsharma@…   |Owner:
 Type:  Bug  |   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
-+-

Comment (by daniloakamine):

 The solution proposed by '''powderflask''' is very interesting and worked
 well.
 This ticket helped me a lot to understand the big problem.

 Thank you all, guys.

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

Re: [Django] #27131: send_mail error if smtp server uses CRAM-MD5 auth method

[Django]

#27131: send_mail error if smtp server uses CRAM-MD5 auth method
---+--
 Reporter:  slavugan   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Core (Mail)|  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords:  send_mail  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by slavugan):

 I have checked for python3 everything is ok, because of with python3
 Django passes password as string to smtplib, so this error is relevant
 only for python2.
 For fix in __init__ in django/core/mail/backends/smtp.py we should add
 something like this:
 {{{
 if self.password.__class__.__name__ == 'unicode':
 try:
 self.password = str(self.password)
 except UnicodeEncodeError:
 pass
 }}}

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

Re: [Django] #16376: Support for database links

[Django]

#16376: Support for database links
-+-
 Reporter:   |Owner:  nobody
  stephane.benchimol@…   |
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle postgres  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by auvipy):

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

Re: [Django] #27131: send_mail error if smtp server uses CRAM-MD5 auth method

[Django]

#27131: send_mail error if smtp server uses CRAM-MD5 auth method
---+--
 Reporter:  slavugan   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Core (Mail)|  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords:  send_mail  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by claudep):

 FYI, I'm currently working on a test for this in the Django test suite.

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

Re: [Django] #27136: Change auth forms' autofocus attribute to HTML5 boolean syntax

[Django]

#27136: Change auth forms' autofocus attribute to HTML5 boolean syntax
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  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
-+-

Comment (by claudep):

 I would also for not bloating the release notes with such "details".

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

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

Re: [Django] #26762: Allow using parts of flatpages without install the app

[Django]

#26762: Allow using parts of flatpages without install the app
---+
 Reporter:  vzima  |Owner:  vzima
 Type:  Bug|   Status:  closed
Component:  contrib.flatpages  |  Version:  1.9
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timgraham):

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


Comment:

 #27109 is the ticket to make the `Flatpage` model swappable.

 #26401 confirmed that you can disable creation of the model with:
 `MIGRATION_MODULES = {'flatpages': None}`

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

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

Re: [Django] #27135: Standardise type value returned by introspection.get_constraints for indexes

[Django]

#27135: Standardise type value returned by introspection.get_constraints for
indexes
-+-
 Reporter:  akki |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  introspection db-| Triage Stage:  Accepted
  indexes 1.11   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * keywords:  introspection => introspection db-indexes 1.11
 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #27136: Change auth forms' autofocus attribute to HTML5 boolean syntax

[Django]

#27136: Change auth forms' autofocus attribute to HTML5 boolean syntax
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  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 timgraham):

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


Comment:

 [https://github.com/django/django/pull/7164 PR] looks good. I'm not sure
 it merits a release note.

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

Re: [Django] #26401: Allow auth machinery to be used without installing auth app

[Django]

#26401: Allow auth machinery to be used without installing auth app
--+
 Reporter:  satchamo  |Owner:  andkon
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:  wontfix
 Keywords:  auth  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by satchamo):

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


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

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

Re: [Django] #26401: Allow auth machinery to be used without installing auth app

[Django]

#26401: Allow auth machinery to be used without installing auth app
--+
 Reporter:  satchamo  |Owner:  andkon
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  auth  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by satchamo):

 Interesting idea. It works:
 {{{
 MIGRATION_MODULES = {
 'auth': None
 }
 }}}

 My complaint was driven by the unnecessary clutter in my database when
 using a custom user model. So now that there is a reasonable solution, I'm
 fine with closing 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/066.18225a2c734081e26e04cf8bf04f0756%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27136: Change auth forms' autofocus attribute to HTML5 boolean syntax

[Django]

#27136: Change auth forms' autofocus attribute to HTML5 boolean syntax
+
   Reporter:  jdufresne |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.auth  |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Similar to #26928.

 The autofocus attribute in auth forms is rendered as `autofocus=""`, but
 it could be rendered as an HTML5 boolean attribute `autofocus`. As docs
 now state Django HTML specifically targets HTML5, might as well use the
 boolean syntax for all boolean attributes.

 Example attribute:
 
https://github.com/django/django/blob/38cf9ef390eb0cd0703d99893f826153865f6ba6/django/contrib/auth/forms.py#L98

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

Re: [Django] #27134: JSONField key values are not escaped correctly in queries

[Django]

#27134: JSONField key values are not escaped correctly in queries
--+--
 Reporter:  onurmatik |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by timgraham):

 * resolution:  fixed => invalid


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

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

Re: [Django] #27132: Test PyLibMCCache on Jenkins

[Django]

#27132: Test PyLibMCCache on Jenkins
--+
 Reporter:  edmorley  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Cache system)   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by timgraham):

 Yes, I installed `libmemcached-dev` on Jenkins.

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

[Django] #27135: Standardise type value returned by introspection.get_constraints for indexes

[Django]

#27135: Standardise type value returned by introspection.get_constraints for
indexes
--+---
 Reporter:  akki  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:  introspection
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 Currently, Django supports introspection of index type for PostgreSQL and
 would be [https://code.djangoproject.com/ticket/27097#ticket supporting it
 for other backends] as well in future.

 Currently the value returned for `type` is arbitrary but it would be
 better to set a standard values associated with each index types (like
 using `Index.suffix` as suggested by Tim Graham). This discussion might
 make it more clear - https://github.com/django/django/pull/7046
 #discussion-diff-74431956

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

Re: [Django] #27134: JSONField key values are not escaped correctly in queries

[Django]

#27134: JSONField key values are not escaped correctly in queries
--+--
 Reporter:  onurmatik |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:  fixed
 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 onurmatik):

 My bad. It was a typo. It is working as expected. Sorry.

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

Re: [Django] #27134: JSONField key values are not escaped correctly in queries

[Django]

#27134: JSONField key values are not escaped correctly in queries
--+--
 Reporter:  onurmatik |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:  fixed
 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 onurmatik):

 * status:  new => closed
 * 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.e3dfcb20849586433632fcb8744f1ed4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26762: Allow using parts of flatpages without install the app

[Django]

#26762: Allow using parts of flatpages without install the app
---+
 Reporter:  vzima  |Owner:  vzima
 Type:  Bug|   Status:  assigned
Component:  contrib.flatpages  |  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
---+

Comment (by aaugustin):

 I proposed to close #26401 as wontfix:
 https://code.djangoproject.com/ticket/26401#comment:8

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

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

Re: [Django] #26401: Allow auth machinery to be used without installing auth app

[Django]

#26401: Allow auth machinery to be used without installing auth app
--+
 Reporter:  satchamo  |Owner:  andkon
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  auth  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by aaugustin):

 FWIW I don't see a lot of value in adding this constraint. Implementing it
 requires a fragile and untestable combination of inner imports to avoid
 touching the models module.

 If the only problem is to avoid creating tables in the database, add a
 `MIGRATION_MODULES` entry for the auth app that points to an empty
 package. I never tried it but I think it should work.

 If this workaround is confirmed to work, I propose to close this ticket as
 wontfix.

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

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

Re: [Django] #26762: Allow using parts of flatpages without install the app

[Django]

#26762: Allow using parts of flatpages without install the app
---+
 Reporter:  vzima  |Owner:  vzima
 Type:  Bug|   Status:  assigned
Component:  contrib.flatpages  |  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
---+

Comment (by aaugustin):

 I also share the concerns expressed in #21719. I made the changes related
 to that ticket very reluctantly to avoid blocking the 1.7 release.

 I would prefer to make the Flatpage model swappable.

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

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

Re: [Django] #21719: Forbid importing models before their application configuration

[Django]

#21719: Forbid importing models before their application configuration
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  app-loading really-  | Triage Stage:  Accepted
  hard   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * keywords:  app-loading => app-loading really-hard


Comment:

 Thankfully, a few years later, we can conclude that the whack-a-mole game
 hasn't gone too far.

 The commits referenced in this ticket were necessary because some public
 APIs were available in the root package of contrib apps and these APIs
 depend on models. The current design of the app-loading process doesn't
 support this use case.

 In the future, unless this is resolved (I'm not sure it ever will), we'll
 avoid creating such APIs. We only had to fix preexisting APIs.

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

Re: [Django] #27130: Allow using the DjangoTemplates engine without configuring settings (was: Cannot use Django Templates in Standalone Mode)

[Django]

#27130: Allow using the DjangoTemplates engine without configuring settings
--+
 Reporter:  AlJohri   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * status:  closed => new
 * type:  Bug => Cleanup/optimization
 * version:  1.10 => master
 * resolution:  invalid =>


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

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

Re: [Django] #27134: JSONField key values are not escaped correctly in queries

[Django]

#27134: JSONField key values are not escaped correctly in queries
--+--
 Reporter:  onurmatik |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.10
 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 onurmatik):

 * component:  Uncategorized => contrib.postgres
 * needs_better_patch:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #27134: JSONField key values are not escaped correctly in queries

[Django]

#27134: JSONField key values are not escaped correctly in queries
---+
 Reporter:  onurmatik  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 If a dictionary stored in a JSONField has a key that contains '/', like a
 URI, it is not possible to use that value as a query parameter.

 {{{
 class Token(models.Model):
 status = JSONField()

 >>> Token.objects.create(status={
 ... '/help/tos': {'remaining': 10},
 ... })

 >>> kwargs = {'status__/help/tos__remaining__gt': 0,}
 >>> Token.objects.filter(**kwargs)
 
 }}}

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

Re: [Django] #27128: A method model.objects.get(pk=obj.pk) returns many objects, but in a database is one.

[Django]

#27128: A method model.objects.get(pk=obj.pk) returns many objects, but in a
database is one.
-+-
 Reporter:  setivolkylany|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.9
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  GenericRelation, | Triage Stage:
  Testing, Models|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by setivolkylany):

 Replying to [comment:6 timgraham]:
 > If the queryset isn't ordered, each time you index
 `get_user_model().objects.all()`, there's no guarantee that the results
 will be in the same order. Try indexing
 `get_user_model().objects.order_by('pk')` instead.


 Your method given me properly results
 {{{
 users = get_user_model().objects.order_by('pk')
 print(users)
 users[0], users[1], users[2], users[3], users[4], users[5]
 }}}



 [, , , ,
 , , , , ]
 (,
  ,
  ,
  ,
  ,
  )

 My default code still return not properly results

 {{{
 users = get_user_model().objects.all()
 print(users)
 users[0], users[1], users[2], users[3], users[4], users[5]
 }}}

 [, , , , , , ,
 , ]
 (,
  ,
  ,
  ,
  ,
  )

 But it not resolve my problem, because my user`s models has default
 sorting by Last_login (see SQL)

 Sorting for the model if I override it
 {{{
 print(get_user_model().objects.only('pk').order_by('pk').query)
 }}}

 SELECT "user"."id" FROM "user" ORDER BY "user"."id" ASC


 Sorting for the model by default is by last_login of users
 {{{
 print(get_user_model().objects.only('pk').query)
 }}}

 SELECT "user"."id" FROM "user" ORDER BY "user"."last_login" DESC

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

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

Re: [Django] #27130: Cannot use Django Templates in Standalone Mode

[Django]

#27130: Cannot use Django Templates in Standalone Mode
-+
 Reporter:  AlJohri  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.10
 Severity:  Normal   |   Resolution:  invalid
 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 aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 Actually it would be nice -- if it's possible -- for the template engine
 to be usable, albeit with limited functionality, outside of a Django
 project, more precisely without having to configure global Django
 settings.

 The cache, i18n, etc. features wouldn't work because they need
 configuration provided by Django settings. That's an expected limitation
 of this feature and it could be documented.

 The biggest problem I can see is that we have no good way to test this,
 this Django's tests run with configured settings.

 Optimistically accepting this requirement, because I think it's a sane
 design principle, but without guarantees that it can be met.

 This ticket is mostly a matter of figuring out and documenting what can
 work and what can't work without settings.

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

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

Re: [Django] #27128: A method model.objects.get(pk=obj.pk) returns many objects, but in a database is one.

[Django]

#27128: A method model.objects.get(pk=obj.pk) returns many objects, but in a
database is one.
-+-
 Reporter:  setivolkylany|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.9
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  GenericRelation, | Triage Stage:
  Testing, Models|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 If the queryset isn't ordered, each time you index
 `get_user_model().objects.all()`, there's no guarantee that the results
 will be in the same order. Try indexing
 `get_user_model().objects.order_by('pk')` instead.

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

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

Re: [Django] #27128: A method model.objects.get(pk=obj.pk) returns many objects, but in a database is one.

[Django]

#27128: A method model.objects.get(pk=obj.pk) returns many objects, but in a
database is one.
-+-
 Reporter:  setivolkylany|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.9
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  GenericRelation, | Triage Stage:
  Testing, Models|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by setivolkylany):

 Replying to [comment:4 timgraham]:
 > Yes, we need a project without `factory_boy` to ensure that the problem
 isn't in that library.
 >
 > You can read about [https://github.com/django/django/tree/master/tests
 Django's test suite] in our
 [https://docs.djangoproject.com/en/dev/internals/contributing/writing-code
 /unit-tests/ contributing docs].

 After many hours debug my code I found a next problem


 {{{
 (Pdb) get_user_model().objects.all()
 [, , , , , , , ]
 (Pdb) get_user_model().objects.all()[0]
 
 (Pdb) get_user_model().objects.all()[1]
 
 (Pdb) get_user_model().objects.all()[2]
 
 (Pdb) get_user_model().objects.all()[3]
 
 (Pdb) get_user_model().objects.all()[4]
 
 (Pdb) get_user_model().objects.all()[5]
 
 }}}

 Problem with a user`s model. It on index [0] [1] and [2] return the same
 user. It leads to dublication in my replies.

 If you know same problem, may be it fixed in the Django 1.10, if  not know
 - I will still debug.

 I wait your response

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

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

Re: [Django] #27133: Explain how to load initial data with a data migration (was: Are fixtures deprecated?)

[Django]

#27133: Explain how to load initial data with a data migration
--+
 Reporter:  xennygrimmato |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #27133: Are fixtures deprecated?

[Django]

#27133: Are fixtures deprecated?
-+-
 Reporter:  xennygrimmato|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * component:  Migrations => Documentation
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 Is the deprecation note and the explanation in the 1.7 release notes
 unclear?

  If an application uses migrations, there is no automatic loading of
 fixtures. Since migrations will be required for applications in Django
 1.9, this behavior is considered deprecated. If you want to load initial
 data for an app, consider doing it in a data migration.

  `initial_data` fixtures are no longer loaded for apps with migrations; if
 you want to load initial data for an app, we suggest you create a
 migration for your application and define a `RunPython` or `RunSQL`
 operation in the operations section of the migration.

 `manage.py loaddata ` still works fine but it doesn't happen
 automatically. #24778 is a ticket about possibly allowing migrations to
 load fixtures.

 Maybe you could propose a documentation clarification as I'm not exactly
 sure what would be helpful to clarify your doubt.

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

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

Re: [Django] #27063: Regex url routing + Localization (prefix_default_language)

[Django]

#27063: Regex url routing + Localization (prefix_default_language)
--+
 Reporter:  keithhackbarth|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.10
 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 urbaniak):

 I've submited pull request - https://github.com/django/django/pull/7162

 Waiting for comments.

 @keithhackbarth, can you test django version from this pull request with
 your project?

 From my tests it's fixing the issue, but want to be sure.

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

Re: [Django] #27063: Regex url routing + Localization (prefix_default_language)

[Django]

#27063: Regex url routing + Localization (prefix_default_language)
--+
 Reporter:  keithhackbarth|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.10
 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 urbaniak):

 We can validate agains the project languages or make sure that language
 prefix ends with /.

 I'll try to submit a pull request with fix this weekend, will try language
 validation approach first.

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

Re: [Django] #27131: send_mail error if smtp server uses CRAM-MD5 auth method

[Django]

#27131: send_mail error if smtp server uses CRAM-MD5 auth method
---+--
 Reporter:  slavugan   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Core (Mail)|  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords:  send_mail  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by claudep):

 Would it be possible to test with Python 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.b6318c22ca4bbca1e9557e4533e50a53%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27133: Are fixtures deprecated?

[Django]

#27133: Are fixtures deprecated?
---+
 Reporter:  xennygrimmato  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Migrations |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Django 1.8's documentation states that fixtures are deprecated for loading
 initial data to models. However, Django 1.10 doesn't state anything about
 the deprecation.
 Can more clarity be given on as to how initial data should ideally be
 loaded into models?

 Links:
 1.10: https://docs.djangoproject.com/en/1.10/howto/initial-data/
 1.8: https://docs.djangoproject.com/en/1.8/howto/initial-data/

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