Re: [Django] #27463: Fix ambiguous variable flake8 warnings

[Django]

#27463: Fix ambiguous variable flake8 warnings
-+-
 Reporter:  Ramin Farajpour  |Owner:  Ramin
  Cami   |  Farajpour Cami
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.10
 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 Ramin Farajpour Cami):

 * has_patch:  0 => 1


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

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

Re: [Django] #27463: Fix ambiguous variable flake8 warnings

[Django]

#27463: Fix ambiguous variable flake8 warnings
-+-
 Reporter:  Ramin Farajpour  |Owner:  Ramin
  Cami   |  Farajpour Cami
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Other) |  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 Ramin Farajpour Cami):

 [https://github.com/django/django/pull/7545 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.f2651185324e10895ed85153903490e8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24423: Combine i18n template tag tests

[Django]

#24423: Combine i18n template tag tests
-+-
 Reporter:  Preston Timmons  |Owner:  Aleksandr
 Type:   |  Sobolev
  Cleanup/optimization   |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by 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/072.b0d4ba1911c620e704ee52fbe9617765%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27478: JSONB_AGG is not available in PostgreSQL 9.4

[Django]

#27478: JSONB_AGG is not available in PostgreSQL 9.4
-+-
   Reporter:  Christian  |  Owner:  nobody
  von Roques |
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  master
  Uncategorized  |
   Severity:  Normal |   Keywords:  JsonAgg JSONB_AGG
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 `django.contrib.postgres.aggregates.general.JsonAgg` uses `JSONB_AGG`. The
 Django test-suite contains a test which fails due to `JSONB_AGG` being
 unavailable as shown below when run against PostgreSQL 9.4. The test is
 already marked as `@skipUnlessDBFeature('has_jsonb_datatype')`, but JSONB
 became available with PostgreSQL 9.4 and `JSONB_AGG` was added in
 PostgreSQL 9.5.
 I currently see three possibilities:
  1. Add a new feature `has_jsonb_agg` and make the test
 `@skipUnlessDBFeature('has_jsonb_agg')`
  2. Add a new feature `has_jsonb_agg` and use `JSON_AGG` instead of
 `JSONB_AGG` when `JSONB_AGG` is unavailable.
 3. Have `has_jsonb_datatype` lie about it not being available in
 PostgreSQL 9.4.
 I prefer and have implemented option 2 and really don't like option 3.

 See my [https://github.com/roques/django/tree/jsonb_agg branch] for my
 initial implementation. — Is there a cleaner way to achieve this besides
 redefining `JsonAgg.as_sql`?

 {{{
 ERROR: test_json_agg (postgres_tests.test_aggregates.TestGeneralAggregate)
 --
 Traceback (most recent call last):
   File "/usr/lib/python3.4/unittest/case.py", line 58, in testPartExecutor
 yield
   File "/usr/lib/python3.4/unittest/case.py", line 577, in run
 testMethod()
   File "/home/roques/tools/django/django/test/testcases.py", line 1113, in
 skip_wrapper
 return test_func(*args, **kwargs)
   File
 "/home/roques/tools/django/tests/postgres_tests/test_aggregates.py", line
 122, in test_json_agg
 values =
 AggregateTestModel.objects.aggregate(jsonagg=JsonAgg('char_field'))
   File "/home/roques/tools/django/django/db/models/manager.py", line 85,
 in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/home/roques/tools/django/django/db/models/query.py", line 352, in
 aggregate
 return query.get_aggregation(self.db, kwargs.keys())
   File "/home/roques/tools/django/django/db/models/sql/query.py", line
 461, in get_aggregation
 result = compiler.execute_sql(SINGLE)
   File "/home/roques/tools/django/django/db/models/sql/compiler.py", line
 829, in execute_sql
 cursor.execute(sql, params)
   File "/home/roques/tools/django/django/db/backends/utils.py", line 64,
 in execute
 return self.cursor.execute(sql, params)
   File "/home/roques/tools/django/django/db/utils.py", line 94, in
 __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/home/roques/tools/django/django/utils/six.py", line 685, in
 reraise
 raise value.with_traceback(tb)
   File "/home/roques/tools/django/django/db/backends/utils.py", line 64,
 in execute
 return self.cursor.execute(sql, params)
 django.db.utils.ProgrammingError: function jsonb_agg(character varying)
 does not exist
 LINE 1: SELECT JSONB_AGG("postgres_tests_aggregatetestmodel"."char_f...
^
 HINT:  No function matches the given name and argument types. You might
 need to add explicit type casts.
 }}}

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

Re: [Django] #27332: Specifying additional ON arguments, and more flexibility with joins

[Django]

#27332: Specifying additional ON arguments, and more flexibility with joins
-+-
 Reporter:  MikiSoft |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (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):

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

Re: [Django] #27367: Document behaviour when several urls have the same name

[Django]

#27367: Document behaviour when several urls have the same name
-+-
 Reporter:  Christoph Schindler  |Owner:  Robert
 Type:   |  Roskam
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1
 * stage:  Ready for checkin => Accepted


Comment:

 The content is looking good and I left some comments for further
 improvement.

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

Re: [Django] #27394: template "floatformat" tag throws ValueError for big numbers in Python 3

[Django]

#27394: template "floatformat" tag throws ValueError for big numbers in Python 3
-+
 Reporter:  mateuszf |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  floatformat python3  | 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):

 Based on those results, I agree the current PR probably makes the most
 sense.

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

Re: [Django] #25569: Add a friendly error report when using select_related() on a reverse relation

[Django]

#25569: Add a friendly error report when using select_related() on a reverse
relation
-+-
 Reporter:  Shai Berger  |Owner:  Vincent
 |  Perez
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 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 Tim Graham):

 The patch turned out a lot more complicated than I thought it would be,
 and I'm not sure if it's worth it. In the original report, Shai said the
 error message refers to fields as "non-existent" but as far as I see, the
 error message is something like:

  FieldError: Invalid field name(s) given in select_related: 'choice_set'.
 Choices are: (none)".

 Since the choices are there, I think it's already clear whether there's a
 typo or if the field isn't supported by `select_related()`. With the
 patch, the error turns into:

  FieldError: Invalid field name(s) given in select_related: 'choice_set'
 (reason: reverse relational field). Choices are: (none).

 We have similar error messages elsewhere and this might set a precedent
 for doing more work to "improve" them similarly. Other opinions welcome.

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

Re: [Django] #27370: Django's Select widget adds a required="required" attribute, even if created with empty_label=True

[Django]

#27370: Django's Select widget adds a required="required" attribute, even if
created with empty_label=True
-+-
 Reporter:  alexpirine   |Owner:  Josef
 Type:   |  Rousek
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
  HTML,Select,wdiget,ModelChoiceField|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josef Rousek):

 I applied those cosmetic changes.

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

Re: [Django] #27467: UserAttributeSimilarityValidator max_similarity=0/1 doesn't work as documented

[Django]

#27467: UserAttributeSimilarityValidator max_similarity=0/1 doesn't work as
documented
-+-
 Reporter:  goblinJoel   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  password management  | Triage Stage:  Accepted
  validation validator   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Good point, I updated the docs in the 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.81784bc48c889006b436f0ec858b398c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27332: Specifying additional ON arguments, and more flexibility with joins

[Django]

#27332: Specifying additional ON arguments, and more flexibility with joins
-+-
 Reporter:  MikiSoft |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (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 Anssi Kääriäinen):

 This is something I've wanted for a long time.

 Some considerations:
   - In general the ORM API tries to avoid SQL specific terms like join.
 Maybe relation would be a better term to use?
   - The API shouldn't edit the current relation, instead it should add a
 new lookup path alias. So: .filtered_relation('translations',
 alias='translation_fi',
 condition=Q(translations__lang='fi')).filter(translation_fi__title=...)

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

Re: [Django] #27332: Specifying additional ON arguments, and more flexibility with joins

[Django]

#27332: Specifying additional ON arguments, and more flexibility with joins
-+-
 Reporter:  MikiSoft |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (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 MikiSoft):

 Awesome! Looking forward to its implementation in Django. :)

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

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

Re: [Django] #27332: Specifying additional ON arguments, and more flexibility with joins

[Django]

#27332: Specifying additional ON arguments, and more flexibility with joins
-+-
 Reporter:  MikiSoft |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (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 Nicolas Delaby):

 Hi,
 I started to look at this one and realized {{{GenericForeignKey}}}
 implemented such functionnality in {{{ get_extra_restriction() }}}

 
https://github.com/django/django/blob/master/django/contrib/contenttypes/fields.py#L437

 So I followed that path, and came up with a PoC implementation (with
 passing tests), following this API:

 {{{#!python
 class ConditionalJoinTests(TestCase):

 @classmethod
 def setUpTestData(cls):
 cls.author1 = Author.objects.create(name='Alice')
 cls.author2 = Author.objects.create(name='Jane')

 cls.book1 = Book.objects.create(title='Poem by Alice',
 editor='A',
 author=cls.author1)

 cls.book2 = Book.objects.create(title='The book by Jane A',
 editor='A',
 author=cls.author2)

 cls.book2 = Book.objects.create(title='The book by Jane B',
 editor='B',
 author=cls.author2)

 def test_conditional_join_query_wo_join(self):
 """
 All Authors are returned because no join is required by the
 filters.
 """
 self.assertQuerysetEqual(
 Author.objects
 .conditional_join('book', title__iexact='poem by alice'),
 ["", ""])

 def test_conditional_join_query_with_join(self):
 self.assertQuerysetEqual(
 Author.objects
 .conditional_join('book', title__iexact='poem by alice')
 .filter(book__isnull=False),
 [""])

 self.assertQuerysetEqual(
 Author.objects
 .conditional_join('book', Q(title__iexact='poem by alice'))
 .filter(book__isnull=False),
 [""])

 def test_conditional_join_query_with_join_multiple(self):
 self.assertQuerysetEqual(
 Author.objects
 .conditional_join('book', title__icontains='jane', editor='B')
 .filter(book__isnull=False),
 [""])
 }}}

 If this proposal receives some interest, I'll be glad to work on preparing
 a pull request to support this use case.

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

Re: [Django] #27402: When using i18n_patterns and prefix_default_language=False, 404 page redirects incorrectly

[Django]

#27402: When using i18n_patterns and prefix_default_language=False, 404 page
redirects incorrectly
-+-
 Reporter:  Hovi |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.10
  Internationalization   |
 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 François Freitag):

 * stage:  Accepted => Ready for checkin


Comment:

 The [https://github.com/django/django/pull/7483 PR] looks good to me.
 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/062.610abb337a19e7f0de5f97c98d15b2b8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27440: Allow reverse() to return a fully qualified URL

[Django]

#27440: Allow reverse() to return a fully qualified URL
-+-
 Reporter:  Mislav Cimperšak |Owner:  Mislav
 |  Cimperšak
 Type:  New feature  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.10
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  reverse, request,| Triage Stage:  Accepted
  full url   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mislav Cimperšak):

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


Comment:

 Closing the issue as discussed on google-groups.

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

Re: [Django] #27448: GIS distance queries use deprecated ST_distance_sphere

[Django]

#27448: GIS distance queries use deprecated ST_distance_sphere
-+-
 Reporter:  Christian von|Owner:  Mjumbe
  Roques |  Poe
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  GIS distance | Triage Stage:  Accepted
  deprecated ST_distance_sphere  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Christian von Roques):

 I've reverted all fixes related to `GeoQuerySet`.
 Please take a look at the code, as I'm unsure about some of the stylistic
 choices I made.

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

Re: [Django] #27477: Use QuerySet.select_for_update() in admin change form to fix race condition

[Django]

#27477: Use QuerySet.select_for_update() in admin change form to fix race 
condition
---+--
 Reporter:  Dave Hall  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Dave Hall):

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

[Django] #27477: Use QuerySet.select_for_update() in admin change form to fix race condition

[Django]

#27477: Use QuerySet.select_for_update() in admin change form to fix race 
condition
-+
   Reporter:  Dave Hall  |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  contrib.admin  |Version:  master
   Severity:  Normal |   Keywords:  admin
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 There is a race condition in the admin change form where a user can edit a
 model instance at the same time as another user. Consider the following
 two operations occurring in parallel:

 1. `ModelAdmin.change_view()`
 2. `User.objects.update(is_superuser=True)`

 If (1) load the model instance, then (2) runs, then (1) saves the model
 instance, the update in (2) will be lost.

 The solution is to call `select_for_update` on the queryset in the
 `changeform_view()` method of `ModelAdmin`.

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

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

Re: [Django] #25240: Add "week" lookup to DateField/DateTimeField

[Django]

#25240: Add "week" lookup to DateField/DateTimeField
-+-
 Reporter:  Chris Foresman   |Owner:  Mads
 |  Jensen
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  QuerySet.extra   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"1446902be48ebf19bfe484371897a2815dd21fca" 1446902b]:
 {{{
 #!CommitTicketReference repository=""
 revision="1446902be48ebf19bfe484371897a2815dd21fca"
 Fixed #25240 -- Added ExtractWeek and exposed it through the __week
 lookup.

 Thanks to Mariusz Felisiak and Tim Graham 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/066.8af26ac97b41de059f535e8f4b5b870b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27370: Django's Select widget adds a required="required" attribute, even if created with empty_label=True

[Django]

#27370: Django's Select widget adds a required="required" attribute, even if
created with empty_label=True
-+-
 Reporter:  alexpirine   |Owner:  Josef
 Type:   |  Rousek
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
  HTML,Select,wdiget,ModelChoiceField|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * stage:  Accepted => Ready for checkin


Comment:

 Patch LGTM pending some cosmetic comments.

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

Re: [Django] #27421: Add support for size, shape, and offset parameters on instantiation of GDALRaster objects.

[Django]

#27421: Add support for size, shape, and offset parameters on instantiation of
GDALRaster objects.
-+-
 Reporter:  Daniel Wiesmann  |Owner:  Daniel
 |  Wiesmann
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  master
 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:"2dc07da497f5ae95ad34a4714e330fae1fa8413c" 2dc07da]:
 {{{
 #!CommitTicketReference repository=""
 revision="2dc07da497f5ae95ad34a4714e330fae1fa8413c"
 Fixed #27421 -- Added shape, size, and offset controls to GDALRaster
 constructor.

 Thanks Tim Graham for the review.
 }}}

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

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

Re: [Django] #27431: Disabled fields are marked as changed in form

[Django]

#27431: Disabled fields are marked as changed in form
+-
 Reporter:  Paul|Owner:  Kenneth Veldman
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  1.10
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"8618a7eaa16bf11f41dd850b42858381f850ce0e" 8618a7e]:
 {{{
 #!CommitTicketReference repository=""
 revision="8618a7eaa16bf11f41dd850b42858381f850ce0e"
 Fixed #27431 -- Prevented disabled form fields from appearing as changed.
 }}}

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

Re: [Django] #27440: Allow reverse() to return a fully qualified URL

[Django]

#27440: Allow reverse() to return a fully qualified URL
-+-
 Reporter:  Mislav Cimperšak |Owner:  Mislav
 |  Cimperšak
 Type:  New feature  |   Status:  assigned
Component:  Core (URLs)  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  reverse, request,| Triage Stage:  Accepted
  full url   |
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


Comment:

 There isn't consensus on the mailing list that passing `request` to
 `reverse()` is the best approach.

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

Re: [Django] #27476: model Integer fields (and derivatives) do not raise a ValidationError while other types do

[Django]

#27476: model Integer fields (and derivatives) do not raise a ValidationError 
while
other types do
-+-
 Reporter:  Romeo Mihalcea   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models, integer, | Triage Stage:
  ValidationError|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Romeo Mihalcea:

Old description:

> I have a model with `Decimal` fields, `Boolean` fields and some `Integer`
> fields. While testing with invalid data (I mostly supplied a string to
> these fields) I noticed that the integer fields do not raise a
> `ValidationError` while all of the other fields do so. Supplying a string
> to all Integer fields raise a `ValueError` instead which looks like all
> other fields have a basic validation in place while the Integers do not.
> I know I'm supposed to perform the validations before the data reaches
> the model but this is testing and I like to make sure everything is as
> intended.
>
> Example:
>

> {{{
> # model
> class Worker(models.Model):
> ...
> disabled = models.BooleanField(default=False)
> max_execution = models.PositiveSmallIntegerField(default=3600,
> null=False)
>

> # testcase
> class TestModelWorker(unittest.TestCase):
>
> def test_max_execution(self):
> # Here we expect a Python ValueError to be raised when providing
> a string
> # as an argument to what is a `PositiveSmallIntegerField`
> with self.assertRaises(ValueError) as e:
> Worker.create(
> name="Worker",
> max_execution='s'
> )
>
> self.assertIn('invalid literal for int() with base 10',
> str(e.exception))
>
> def test_disabled(self):
> # While here we can expect a `ValidationError` when providing a
> string to a `BooleanField`
> with self.assertRaises(ValidationError) as e:
> Worker.create(
> name="Worker",
> disabled='s'
> )
> }}}

New description:

 I have a model with `Decimal` fields, `Boolean` fields and some `Integer`
 fields. While testing with invalid data (I mostly supplied a string to
 these fields) I noticed that the integer fields do not raise a
 `ValidationError` while all of the other fields do so. Supplying a string
 to all Integer fields raise a `ValueError` instead which looks like all
 other fields have a basic validation in place while the Integers do not. I
 know I'm supposed to perform the validations before the data reaches the
 model but this is testing and I like to make sure everything is as
 intended.

 Example:


 {{{
 # model
 class Worker(models.Model):
 ...
 disabled = models.BooleanField(default=False)
 max_execution = models.PositiveSmallIntegerField(default=3600,
 null=False)


 # testcase
 class TestModelWorker(unittest.TestCase):

 def test_max_execution(self):
 # Here we expect a Python ValueError to be raised when providing a
 string
 # as an argument to what is a `PositiveSmallIntegerField`
 with self.assertRaises(ValueError) as e:
 Worker.create(
 name="Worker",
 max_execution='s'
 )

 self.assertIn('invalid literal for int() with base 10',
 str(e.exception))

 def test_disabled(self):
 # While here we can expect a `ValidationError` when providing a
 string to a `BooleanField`
 with self.assertRaises(ValidationError) as e:
 Worker.create(
 name="Worker",
 disabled='s'
 )
 self.assertIn('value must be either True or False',
 str(e.exception))
 }}}

--

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

Re: [Django] #27476: model Integer fields (and derivatives) do not raise a ValidationError while other types do

[Django]

#27476: model Integer fields (and derivatives) do not raise a ValidationError 
while
other types do
-+-
 Reporter:  Romeo Mihalcea   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models, integer, | Triage Stage:
  ValidationError|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Romeo Mihalcea):

 Replying to [comment:2 Romeo Mihalcea]:
 Added some modifications

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

Re: [Django] #27476: model Integer fields (and derivatives) do not raise a ValidationError while other types do

[Django]

#27476: model Integer fields (and derivatives) do not raise a ValidationError 
while
other types do
-+-
 Reporter:  Romeo Mihalcea   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models, integer, | Triage Stage:
  ValidationError|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Romeo Mihalcea:

Old description:

> I have a model with `Decimal` fields, `Boolean` fields and some `Integer`
> fields. While testing with invalid data (I mostly supplied a string to
> these fields) I noticed that the integer fields do not raise a
> `ValidationError` while all of the other fields do so. Supplying a string
> to all Integer fields raise a `ValueError` instead which looks like all
> other fields have a basic validation in place while the Integers do not.
> I know I'm supposed to perform the validations before the data reaches
> the model but this is testing and I like to make sure everything is as
> intended.

New description:

 I have a model with `Decimal` fields, `Boolean` fields and some `Integer`
 fields. While testing with invalid data (I mostly supplied a string to
 these fields) I noticed that the integer fields do not raise a
 `ValidationError` while all of the other fields do so. Supplying a string
 to all Integer fields raise a `ValueError` instead which looks like all
 other fields have a basic validation in place while the Integers do not. I
 know I'm supposed to perform the validations before the data reaches the
 model but this is testing and I like to make sure everything is as
 intended.

 Example:


 {{{
 # model
 class Worker(models.Model):
 ...
 disabled = models.BooleanField(default=False)
 max_execution = models.PositiveSmallIntegerField(default=3600,
 null=False)


 # testcase
 class TestModelWorker(unittest.TestCase):

 def test_max_execution(self):
 # Here we expect a Python ValueError to be raised when providing a
 string
 # as an argument to what is a `PositiveSmallIntegerField`
 with self.assertRaises(ValueError) as e:
 Worker.create(
 name="Worker",
 max_execution='s'
 )

 self.assertIn('invalid literal for int() with base 10',
 str(e.exception))

 def test_disabled(self):
 # While here we can expect a `ValidationError` when providing a
 string to a `BooleanField`
 with self.assertRaises(ValidationError) as e:
 Worker.create(
 name="Worker",
 disabled='s'
 )
 }}}

--

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

Re: [Django] #27472: GEOSGeometry('POINT EMPTY').ogr crashes

[Django]

#27472: GEOSGeometry('POINT EMPTY').ogr crashes
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 I think however you want to provide fixes will be fine. Perhaps multiple
 commits referencing the same ticket would be fine.

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

Re: [Django] #27476: model Integer fields (and derivatives) do not raise a ValidationError while other types do

[Django]

#27476: model Integer fields (and derivatives) do not raise a ValidationError 
while
other types do
-+-
 Reporter:  Romeo Mihalcea   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models, integer, | Triage Stage:
  ValidationError|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Can you please provide some sample code that demonstrates the issue?

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

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

Re: [Django] #27458: Oracle backend giving ORA-00911 : Invalid Character, querying with a literal "%s"

[Django]

#27458: Oracle backend giving ORA-00911 : Invalid Character, querying with a
literal "%s"
-+-
 Reporter:  Gabriel Canto de |Owner:  Andrew
  Souza  |  Nester
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Oracle   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Andrew Nester):

 * needs_better_patch:  1 => 0


Comment:

 I've updated pull request, that's why Patch needs improvement set to No

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

Re: [Django] #25251: Inconsistent availability of data migrations in TransactionTestCase when using --keepdb

[Django]

#25251: Inconsistent availability of data migrations in TransactionTestCase when
using --keepdb
-+-
 Reporter:  David Szotten|Owner:  Romain
 |  Garrigues
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  1.8
 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 Romain Garrigues):

 * owner:  nobody => Romain Garrigues
 * status:  new => assigned


Comment:

 I updated the MR according to my discussion with @aaugustin.
 It impacted the `DiscoverRunner` explicit test ordering. I didn't want to
 update the current tests to ensure backward-compatibility, I created new
 ones for `TransactionTestCase` tests ordering.

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

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

Re: [Django] #27448: GIS distance queries use deprecated ST_distance_sphere

[Django]

#27448: GIS distance queries use deprecated ST_distance_sphere
-+-
 Reporter:  Christian von|Owner:  Mjumbe
  Roques |  Poe
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  GIS distance | Triage Stage:  Accepted
  deprecated ST_distance_sphere  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 Thanks! As stated on the PR and in comment:5, I don't think we should
 update the deprecated `GeoQuerySet`-related names. Let's concentrate on
 database function names (as in
 https://docs.djangoproject.com/en/1.10/ref/contrib/gis/functions/).

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