Re: [Django] #30248: Implement case insensitive fields in Sqlite

[Django]

#30248: Implement case insensitive fields in Sqlite
-+-
 Reporter:  Stuart Axon  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  sqlite citext| Triage Stage:
  postgres   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Nick Pope):

 Replying to [comment:1 Carlton Gibson]:
 > At that point I'm wondering if similar isn't supported across all four
 supported backends, in which case would we want to pull the fields out of
 `contrib`...?

 If this is possible, it would then make sense to implement
 {{{CharField(insensitive=True)}}}, with default of {{{False}}}. Perhaps
 this could also work with {{{TextField}}}?

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

Re: [Django] #30249: Deprecate re-raising view exceptions from test client in tests

[Django]

#30249: Deprecate re-raising view exceptions from test client in tests
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jon Dufresne):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #30161: View decorators docs should mention how to decorate class based views

[Django]

#30161: View decorators docs should mention how to decorate class based views
-+-
 Reporter:  Jaap Roes|Owner:  Alexandru
 Type:   |  Balan
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  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
-+-

Comment (by Tim Graham ):

 In [changeset:"14240e491e8e10f9627787d0ba9e76ac0bdf7371" 14240e4]:
 {{{
 #!CommitTicketReference repository=""
 revision="14240e491e8e10f9627787d0ba9e76ac0bdf7371"
 [2.2.x] Fixed #30161 -- Added how to decorate class-based views to view
 decorators docs.

 Backport of 406de977ea1a6429535d21240e3ecdac06d4516c from master.
 }}}

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

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

Re: [Django] #30161: View decorators docs should mention how to decorate class based views

[Django]

#30161: View decorators docs should mention how to decorate class based views
-+-
 Reporter:  Jaap Roes|Owner:  Alexandru
 Type:   |  Balan
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  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:"406de977ea1a6429535d21240e3ecdac06d4516c" 406de977]:
 {{{
 #!CommitTicketReference repository=""
 revision="406de977ea1a6429535d21240e3ecdac06d4516c"
 Fixed #30161 -- Added how to decorate class-based views to view decorators
 docs.
 }}}

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

Re: [Django] #21039: Support Postgres "CREATE INDEX CONCURRENTLY" in migrations

[Django]

#21039: Support Postgres "CREATE INDEX CONCURRENTLY" in migrations
-+
 Reporter:  FunkyBob |Owner:  Dan Tao
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  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


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

Re: [Django] #30161: View decorators docs should mention how to decorate class based views

[Django]

#30161: View decorators docs should mention how to decorate class based views
-+-
 Reporter:  Jaap Roes|Owner:  Alexandru
 Type:   |  Balan
  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:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #30245: Run tests matching a filter (Python 3.7 -k option)

[Django]

#30245: Run tests matching a filter (Python 3.7 -k option)
-+-
 Reporter:  François Freitag |Owner:  François
 |  Freitag
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  test,unittest,filter   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by François Freitag):

 * needs_better_patch:  1 => 0


Comment:

 Following mailing list consensus to remove the `-k` shorthand for
 `--keepdb` without replacement, the
 [https://github.com/django/django/pull/11067 PR] has been updated and uses
 `-k` to select tests.

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

Re: [Django] #18707: Test client doesn't allow testing 500 responses content

[Django]

#18707: Test client doesn't allow testing 500 responses content
-+-
 Reporter:  ricardokirkner@… |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Testing framework|  Version:  1.6
 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
-+-

Comment (by Jon Dufresne):

 > However, I would like to suggest that raise_view_exception=False become
 the default after a deprecation period and perhaps eventually dropping the
 old behavior (again, after a deprecation period).

 I've followed up with this suggestion in #30249

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

[Django] #30249: Deprecate re-raising view exceptions from test client in tests

[Django]

#30249: Deprecate re-raising view exceptions from test client in tests
+
   Reporter:  Jon Dufresne  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Testing framework |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 |
+
 This is a continuation of the work started in ticket #18707.

 Set for removal in 4.0.

 By no longer re-raising the view exceptions in tests, we'll move the test
 `Client` closer to behaving like a real world HTTP client. This assists
 integration tests by providing more realistic side effects to test
 against. Instead of altering the behavior under test, integration tests
 can more reliably test the full stack, including the error handlers (which
 were previously skipped in the default configuration).

 Additionally, this behavior is duplicating the setting
 [https://docs.djangoproject.com/en/2.2/ref/settings/#debug-propagate-
 exceptions DEBUG_PROPAGATE_EXCEPTIONS].

 Should a test want this behavior explicitly, it is already available by
 adjusting this setting. For example:

 {{{
 class MyTest(TestCase):
 @override_settings(DEBUG_PROPAGATE_EXCEPTIONS=True)
 def test_raises_exception(self):
 with self.assertRaises(KeyError):
 self.client.get('/broken_view/')
 }}}

 To assist in the deprecation period, I've opted to allow users to force
 the new behavior and silence warnings by setting
 `DEBUG_PROPAGATE_EXCEPTIONS` to the alternative falsey value `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/052.f3caad2319a0619689616dcb41f03551%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30248: Implement case insensitive fields in Sqlite

[Django]

#30248: Implement case insensitive fields in Sqlite
-+-
 Reporter:  Stuart Axon  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  sqlite citext| Triage Stage:
  postgres   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * status:  new => closed
 * resolution:   => needsinfo
 * version:  2.1 => master
 * component:  Uncategorized => Database layer (models, ORM)


Comment:

 Hi Stuart.

 Short answer, "Yes, maybe". :)

 First off would be proof-of-concept fields, maybe in a third-party
 (similar to exist for MySQL and Postgres already). The `CIText` fields are
 fairly minimal, so there may not be much here.

 Then an approach to the DevelopersMailingList to see if there were
 appetite to include such fields in Django itself. (At that point I'm
 wondering if similar isn't supported across all four supported backends,
 in which case would we want to pull the fields out of `contrib`...?) — The
 issue tracker isn't really the best place for that conversation.

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

Re: [Django] #30247: ModelMultipleChoiceField Bug - Initial Values has to be in queryset, does not make sense

[Django]

#30247: ModelMultipleChoiceField Bug - Initial Values has to be in queryset, 
does
not make sense
-+-
 Reporter:  Josef Korbel |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  2.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
  ModelMultipleChoiceField   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 You've misunderstood what's going on here. `queryset` in this case means
 the set of allowed values. All values, whether initial or not, must be in
 `queryset`.

 If you're not clear on this please see
 TicketClosingReasons/UseSupportChannels.

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

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

Re: [Django] #30216: Document BooleanField is no longer blank=True in Django 2.1+

[Django]

#30216: Document BooleanField is no longer blank=True in Django 2.1+
--+
 Reporter:  Ed Morley |Owner:  sejd0n
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  2.1
 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 sejd0n):

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


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

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

[Django] #30248: Implement case insensitive fields in Sqlite

[Django]

#30248: Implement case insensitive fields in Sqlite
-+-
   Reporter:  Stuart |  Owner:  nobody
  Axon   |
   Type:  New| Status:  new
  feature|
  Component: |Version:  2.1
  Uncategorized  |   Keywords:  sqlite citext
   Severity:  Normal |  postgres
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Sqlite supports case insensitive fields by setting COLLATE NOCASE.

 This works as you would expect for SELECT and INSERT.


 It would be great to have equivalents to the CIText fields in
 postgres.contrib - this would make it a lot easier to unit test code using
 those fields.

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

Re: [Django] #30247: ModelMultipleChoiceField Bug - Initial Values has to be in queryset, does not make sense

[Django]

#30247: ModelMultipleChoiceField Bug - Initial Values has to be in queryset, 
does
not make sense
-+-
 Reporter:  Josef Korbel |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  ModelMultipleChoiceField   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Josef Korbel):

 * component:  Uncategorized => Forms
 * type:  Uncategorized => Bug


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

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

[Django] #30247: ModelMultipleChoiceField Bug - Initial Values has to be in queryset, does not make sense

[Django]

#30247: ModelMultipleChoiceField Bug - Initial Values has to be in queryset, 
does
not make sense
-+-
   Reporter:  Josef  |  Owner:  nobody
  Korbel |
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  2.1
  Uncategorized  |   Keywords:
   Severity:  Normal |  ModelMultipleChoiceField
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When using ModelMultipleChoiceField, the initial values need to be in the
 queryset, or the widget will be empty. As my queryset is collection of
 unassigned objects, my initial will never by in my queryset, thus making
 this undoable for me, here are more details on SO.

 https://stackoverflow.com/questions/54941814/django-
 modelmultiplechoicefield-1n-initial/54998957#54998957

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

Re: [Django] #30246: Using an annotated field calculated with django.db.models.functions.Extract in aggregate results in ProgrammingError

[Django]

#30246: Using an annotated field calculated with 
django.db.models.functions.Extract
in aggregate results in ProgrammingError
-+-
 Reporter:  Jan Baryła   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  query, aggregate,| Triage Stage:  Accepted
  extract, annotate, postgresql  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jan Baryła):

 I can confirm that Simon's PR fixes the issue. Great job!

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