Re: [Django] #30719: Unable to use OuterRef(Expression(...))

[Django]

#30719: Unable to use OuterRef(Expression(...))
-+-
 Reporter:  Matthew Schinckel|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  Subquery, OuterRef,  | Triage Stage:
  Expression |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Simon Charette):

 > I'll close this (and the PR), but I still have an itchy feeling that
 there is a use-case for having an expression inside the OuterRef - but
 maybe it's always that the Expression itself would just have the OuterRef
 inside it...

 I think this should not happen; we don't allow expressions in `F` either
 since it's just an unresolved reference to a column. In a sense `OuterRef`
 is really just a way to express `F` for an outer query.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.97b562777493d4b3f584cbef1eb6e34f%40djangoproject.com.

Re: [Django] #30719: Unable to use OuterRef(Expression(...))

[Django]

#30719: Unable to use OuterRef(Expression(...))
-+-
 Reporter:  Matthew Schinckel|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  Subquery, OuterRef,  | Triage Stage:
  Expression |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Matthew Schinckel):

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


Comment:

 Yeah, that does indeed work.

 I'll close this (and the PR), but I still have an itchy feeling that there
 is a use-case for having an expression inside the OuterRef - but maybe
 it's always that the Expression itself would just have the OuterRef inside
 it...

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

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

Re: [Django] #30719: Unable to use OuterRef(Expression(...))

[Django]

#30719: Unable to use OuterRef(Expression(...))
-+-
 Reporter:  Matthew Schinckel|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Subquery, OuterRef,  | Triage Stage:
  Expression |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Matthew Schinckel):

 Hmm. I didn't think to use that syntax, let me test it.

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

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

Re: [Django] #30719: Unable to use OuterRef(Expression(...))

[Django]

#30719: Unable to use OuterRef(Expression(...))
-+-
 Reporter:  Matthew Schinckel|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Subquery, OuterRef,  | Triage Stage:
  Expression |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Simon Charette):

 Something seems off here, the `OuterRef` should not be nested. Did you
 mean

 {{{#!python
 staff = Person.objects.filter(
 first_name__iexact=Func(
 OuterRef('data'), Value('FirstName'),
 function='JSONB_EXTRACT_PATH_TEXT', output_field=models.TextField()
 )
 )
 return self.annotate(candidates=Array(staff.values('pk')))
 }}}

 If that's the case then yes I believe we should add support for that, I
 was under the impression it was already supported.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.b4b90d58b8b98033a555f64d5f512290%40djangoproject.com.

[Django] #30719: Unable to use OuterRef(Expression(...))

[Django]

#30719: Unable to use OuterRef(Expression(...))
-+-
   Reporter:  Matthew|  Owner:  nobody
  Schinckel  |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  master
  layer (models, ORM)|   Keywords:  Subquery, OuterRef,
   Severity:  Normal |  Expression
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 Whilst refactoring some code today, I noticed I had the following code in
 a queryset method:


 {{{
 staff = Person.objects.filter(
 first_name__iexact=OuterRef('_first_name'),
 ...
 )

 return self.annotate(
 _first_name=Func(F('data'), Value('FirstName'),
 function='JSONB_EXTRACT_PATH_TEXT', output_field=models.TextField()
 ).annotate(
 candidates=Array(staff.values('pk'))
 )
 }}}


 It's an annoyance to have to annotate on the expression to the outer
 queryset, and then reference it in the inner queryset. It's also forcing
 the database to do more work, because the SQL that is generated will
 result in the expression being evaluated multiple times.

 Instead, it will be much nicer to write:

 {{{
 staff = Person.objects.filter(
 first_name__iexact=OuterRef(
 Func(OuterRef('data'), Value('FirstName'),
 function='JSONB_EXTRACT_PATH_TEXT', output_field=models.TextField()
 )
 )

 return self.annotate(candidates=Array(staff.values('pk')))
 }}}

 (Note the second use of OuterRef there because we are referring to the
 `data` from the outer queryset).

 I believe the only change that is required to enable this is in
 OuterRef.resolve_expression (and I have a working prototype on my 1.11
 codebase).


 Does this seem like a sane change to the functionality?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.1dedb39d34b2e987439093a97460e376%40djangoproject.com.

Re: [Django] #28919: Add support for Common Table Expression (CTE) queries

[Django]

#28919: Add support for Common Table Expression (CTE) queries
-+-
 Reporter:  Daniel Miller|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Javier Buzzi):

 Any updates?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.adabc5346fc69e02908b226d75bcf4e6%40djangoproject.com.

Re: [Django] #30714: Add a system check against SESSION_EXPIRE_AT_BROWSER_CLOSE and SESSION_COOKIE_AGE both being set

[Django]

#30714: Add a system check against SESSION_EXPIRE_AT_BROWSER_CLOSE and
SESSION_COOKIE_AGE both being set
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  New feature  |   Status:  closed
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Adam (Chainz) Johnson):

 I think the confusion was that the behaviours don't combine. You can't
 have a session that is maximum 30 minutes but also disappears if the
 browser is closed. The docs could be clearer but I think a check is the
 easiest way to prevent such misconfiguration,

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.9eff3d241cabea4ff368d1450befec7b%40djangoproject.com.

Re: [Django] #30716: ArrayContains does not call get_db_prep_value method for base field

[Django]

#30716: ArrayContains does not call get_db_prep_value method for base field
--+--
 Reporter:  Andrey Torsunov   |Owner:  (none)
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  2.2
 Severity:  Normal|   Resolution:  duplicate
 Keywords:  array postgres| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by felixxm):

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


Comment:

 Duplicate of #29391.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.5dc0947b41647fc97f5364ba1083939a%40djangoproject.com.

Re: [Django] #30686: Improve utils.text.Truncator to use a full HTML parser.

[Django]

#30686: Improve utils.text.Truncator  to use a full HTML parser.
---+
 Reporter:  Thomas Hooper  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  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 Carlton Gibson):

 * cc: Jon Dufresne (added)


Comment:

 Paging Jon, to ask his opinion on this.

 Hey Jon, I see you've made a number of PRs to both html5lib, and bleach.

 To me, at this point, html5lib essentially looks unmaintained. I don't
 have personal capacity to give to it, as cool as it is as a project.
 Arguably we (Fellows) could allocate it _some_ time, since we spend a fair
 bit already messing around with regexes but that would be small, and we
 couldn't take it on whole, so can I ask your thoughts?

 Is html5lib in trouble? If so, as a user, what are your plans, if any? And
 from that, what do you think about Django adopting it? What's the
 alternative?

 Thanks for the thought and insight.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.aa893e8f5706cde01b3654566f92705e%40djangoproject.com.

Re: [Django] #28107: Can't perform annotation on related table when un-managed model is backed by a DB view

[Django]

#28107: Can't perform annotation on related table when un-managed model is 
backed
by a DB view
-+-
 Reporter:  powderflask  |Owner:  Vojtěch
 |  Boček
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 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 felixxm):

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


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

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

Re: [Django] #30718: blocktrans is crashing when using percent signs when no variables were supplied

[Django]

#30718: blocktrans is crashing when using percent signs when no variables were
supplied
-+-
 Reporter:  NyanKiyoshi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  2.2
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  i18n blocktrans  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by NyanKiyoshi:

Old description:

> When using `blocktrans` without supplying any variables and a translator
> puts a percent sign as a translation, a crash occurs.
>
> For example, using this template snippet:
> {{{
> {% blocktrans context "Taxes" %}
>   tax_rate * price
> {% endblocktrans %}
> }}}
>
> If one translates it to:
> {{{
>   % imposto * preço
> }}}
>
> It will raise:
> {{{
> TypeError: %i format: a number is required, not dict
> }}}
>
> Where stack is:
> {{{
>   File "django/core/handlers/exception.py", line 34, in inner
> response = get_response(request)
>   File "django/core/handlers/base.py", line 145, in _get_response
> response = self.process_exception_by_middleware(e, request)
>   File "django/core/handlers/base.py", line 143, in _get_response
> response = response.render()
>   File "django/template/response.py", line 106, in render
> self.content = self.rendered_content
>   File "django/template/response.py", line 83, in rendered_content
> content = template.render(context, self._request)
>   File "django/template/backends/django.py", line 61, in render
> return self.template.render(context)
>   File "django/template/base.py", line 171, in render
> return self._render(context)
>   File "django/template/base.py", line 163, in _render
> return self.nodelist.render(context)
>   File "django/template/base.py", line 937, in render
> bit = node.render_annotated(context)
>   File "django/template/base.py", line 904, in render_annotated
> return self.render(context)
>   File "django/template/loader_tags.py", line 150, in render
> return compiled_parent._render(context)
>   File "django/template/base.py", line 163, in _render
> return self.nodelist.render(context)
>   File "django/template/base.py", line 937, in render
> bit = node.render_annotated(context)
>   File "django/template/base.py", line 904, in render_annotated
> return self.render(context)
>   File "django/template/loader_tags.py", line 150, in render
> return compiled_parent._render(context)
>   File "django/template/base.py", line 163, in _render
> return self.nodelist.render(context)
>   File "django/template/base.py", line 937, in render
> bit = node.render_annotated(context)
>   File "django/template/base.py", line 904, in render_annotated
> return self.render(context)
>   File "django/template/loader_tags.py", line 62, in render
> result = block.nodelist.render(context)
>   File "django/template/base.py", line 937, in render
> bit = node.render_annotated(context)
>   File "django/template/base.py", line 904, in render_annotated
> return self.render(context)
>   File "django/templatetags/i18n.py", line 161, in render
> result = result % data
> }}}
>
> The crashing line being this one:
> [https://github.com/django/django/blob/1e429df748867097451bf0b45d1080ae6828d921/django/templatetags/i18n.py#L161
> 1e429df7488/django/templatetags/i18n.py#L161]
>
> The PO compiler doesn't check the validity of the provided translation as
> the flag [https://www.gnu.org/software/gettext/manual/html_node/PO-
> Files.html python-format] flag is not generated in the PO file is not
> set.
>
> We should whether not try to format the string if there is no variable,
> or force the `python-format` flag to be set to prevent translators from
> breaking the templates.

New description:

 When using `blocktrans` without supplying any variables and a translator
 puts a percent sign as a translation, a crash occurs.

 For example, using this template snippet:
 {{{
 {% blocktrans context "Taxes" %}
   tax_rate * price
 {% endblocktrans %}
 }}}

 If one translates it to:
 {{{
   % imposto * preço
 }}}

 It will raise:
 {{{
 TypeError: %i format: a number is required, not dict
 }}}

 Where stack is:
 {{{
   File "django/core/handlers/exception.py", line 34, in inner
 response = get_response(request)
   File "django/core/handlers/base.py", line 145, in _get_response
 response = self.process_exception_by_middleware(e, request)
   File "django/core/handlers/base.py", line 143, in 

[Django] #30718: blocktrans is crashing when using percent signs when no variables were supplied

[Django]

#30718: blocktrans is crashing when using percent signs when no variables were
supplied
-+-
   Reporter: |  Owner:  nobody
  NyanKiyoshi|
   Type:  Bug| Status:  new
  Component: |Version:  2.2
  Internationalization   |
   Severity:  Normal |   Keywords:  i18n blocktrans
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When using `blocktrans` without supplying any variables and a translator
 puts a percent sign as a translation, a crash occurs.

 For example, using this template snippet:
 {{{
 {% blocktrans context "Taxes" %}
   tax_rate * price
 {% endblocktrans %}
 }}}

 If one translates it to:
 {{{
   % imposto * preço
 }}}

 It will raise:
 {{{
 TypeError: %i format: a number is required, not dict
 }}}

 Where stack is:
 {{{
   File "django/core/handlers/exception.py", line 34, in inner
 response = get_response(request)
   File "django/core/handlers/base.py", line 145, in _get_response
 response = self.process_exception_by_middleware(e, request)
   File "django/core/handlers/base.py", line 143, in _get_response
 response = response.render()
   File "django/template/response.py", line 106, in render
 self.content = self.rendered_content
   File "django/template/response.py", line 83, in rendered_content
 content = template.render(context, self._request)
   File "django/template/backends/django.py", line 61, in render
 return self.template.render(context)
   File "django/template/base.py", line 171, in render
 return self._render(context)
   File "django/template/base.py", line 163, in _render
 return self.nodelist.render(context)
   File "django/template/base.py", line 937, in render
 bit = node.render_annotated(context)
   File "django/template/base.py", line 904, in render_annotated
 return self.render(context)
   File "django/template/loader_tags.py", line 150, in render
 return compiled_parent._render(context)
   File "django/template/base.py", line 163, in _render
 return self.nodelist.render(context)
   File "django/template/base.py", line 937, in render
 bit = node.render_annotated(context)
   File "django/template/base.py", line 904, in render_annotated
 return self.render(context)
   File "django/template/loader_tags.py", line 150, in render
 return compiled_parent._render(context)
   File "django/template/base.py", line 163, in _render
 return self.nodelist.render(context)
   File "django/template/base.py", line 937, in render
 bit = node.render_annotated(context)
   File "django/template/base.py", line 904, in render_annotated
 return self.render(context)
   File "django/template/loader_tags.py", line 62, in render
 result = block.nodelist.render(context)
   File "django/template/base.py", line 937, in render
 bit = node.render_annotated(context)
   File "django/template/base.py", line 904, in render_annotated
 return self.render(context)
   File "django/templatetags/i18n.py", line 161, in render
 result = result % data
 }}}

 The crashing line being this one:
 
[https://github.com/django/django/blob/1e429df748867097451bf0b45d1080ae6828d921/django/templatetags/i18n.py#L161
 1e429df7488/django/templatetags/i18n.py#L161]

 The PO compiler doesn't check the validity of the provided translation as
 the flag [https://www.gnu.org/software/gettext/manual/html_node/PO-
 Files.html python-format] flag is not generated in the PO file is not set.

 We should whether not try to format the string if there is no variable, or
 force the `python-format` flag to be set to prevent translators from
 breaking the templates.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.ba6572d366067658d448387879d28122%40djangoproject.com.

[Django] #30717: Session model has a useless LIKE index

[Django]

#30717: Session model has a useless LIKE index
+
   Reporter:  Ran Benita|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.sessions  |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 |
+
 The Session model has a CharField primary key, `session_key`. As a primary
 key, it is indexed, but as a CharField, it has two indexes created, one
 for equality matches and one for LIKE matches. Sessions are not (and
 should not) be matched with LIKE, so the index is unused. It will be
 better to remove it -- will reduce space usage and slightly reduce INSERT
 and DELETE overhead.

 

 I use PostgreSQL, version 11. I checked whether the index is used with the
 following query:

 {{{
 select * from pg_stat_all_indexes where indexrelname like
 'django_session_session_key_%_like';
 }}}

 Surprisingly, it is used, every time a user logs out. For some reason,
 postgres decides to use it on DELETE (and not for SELECT):

 {{{
 # explain delete from django_session where session_key = '1000';
  QUERY PLAN
 
-
  Delete on django_session  (cost=0.43..8.45 rows=1 width=6)
->  Index Scan using django_session_session_key_1136ae038ed61e94_like
 on django_session  (cost=0.43..8.45 rows=1 width=6)
  Index Cond: ((session_key)::text = '1000'::text)
 }}}

 However, when the index is dropped, the pkey index is used instead:

 {{{
 # drop index django_session_session_key_1136ae038ed61e94_like;
 DROP INDEX
 # explain delete from django_session where session_key = '1001';
QUERY PLAN
 

  Delete on django_session  (cost=0.43..8.45 rows=1 width=6)
->  Index Scan using django_session_pkey on django_session
 (cost=0.43..8.45 rows=1 width=6)
  Index Cond: ((session_key)::text = '1001'::text)
 }}}

 so the LIKE index is not actually helpful.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.445090fddca38d47a8a6dc85c569fc89%40djangoproject.com.

[Django] #30716: ArrayContains does not call get_db_prep_value method for base field

[Django]

#30716: ArrayContains does not call get_db_prep_value method for base field
-+-
   Reporter:  Andrey |  Owner:  (none)
  Torsunov   |
   Type:  Bug| Status:  new
  Component: |Version:  2.2
  contrib.postgres   |
   Severity:  Normal |   Keywords:  array postgres
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Example:

 {{{

 import enum
 from django.db import models
 from django.contrib.postgres.fields.array import ArrayField


 class EnumField(models.TextField):
 # get_db_prep_value calls this method
 def get_prep_value(val):
 return val.name


 class SomeEnum(enum.Enum):
 A = enum.auto()
 B = enum.auto()


 class SomeModel(models.Model):
 array = ArrayField(EnumField())


 SomeModel.objects.filter(array__contains=[SomeEnum.A, SomeEnum.B]).all()
 }}}



 Will cause:

 {{{
File "/home/user/.local/share/virtualenvs/tko-ck5fDNTQ/lib/python3.7
 /site-packages/django/db/models/query.py", line 274, in __iter__
 self._fetch_all()
   File "/home/user/.local/share/virtualenvs/tko-ck5fDNTQ/lib/python3.7
 /site-packages/django/db/models/query.py", line 1242, in _fetch_all
 self._result_cache = list(self._iterable_class(self))
   File "/home/user/.local/share/virtualenvs/tko-ck5fDNTQ/lib/python3.7
 /site-packages/django/db/models/query.py", line 55, in __iter__
 results = compiler.execute_sql(chunked_fetch=self.chunked_fetch,
 chunk_size=self.chunk_size)
   File "/home/user/.local/share/virtualenvs/tko-ck5fDNTQ/lib/python3.7
 /site-packages/django/db/models/sql/compiler.py", line 1100, in
 execute_sql
 cursor.execute(sql, params)
   File "/home/user/.local/share/virtualenvs/tko-ck5fDNTQ/lib/python3.7
 /site-packages/raven/contrib/django/client.py", line 127, in execute
 return real_execute(self, sql, params)
   File "/home/user/.local/share/virtualenvs/tko-ck5fDNTQ/lib/python3.7
 /site-packages/django/db/backends/utils.py", line 67, in execute
 return self._execute_with_wrappers(sql, params, many=False,
 executor=self._execute)
   File "/home/user/.local/share/virtualenvs/tko-ck5fDNTQ/lib/python3.7
 /site-packages/django/db/backends/utils.py", line 76, in
 _execute_with_wrappers
 return executor(sql, params, many, context)
   File "/home/user/.local/share/virtualenvs/tko-ck5fDNTQ/lib/python3.7
 /site-packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
   File "/home/user/.local/share/virtualenvs/tko-ck5fDNTQ/lib/python3.7
 /site-packages/django/db/utils.py", line 89, in __exit__
 raise dj_exc_value.with_traceback(traceback) from exc_value
   File "/home/user/.local/share/virtualenvs/tko-ck5fDNTQ/lib/python3.7
 /site-packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
 django.db.utils.ProgrammingError: can't adapt type 'SomeEnum'
 }}}


 It can be fixed via overriding `get_db_prep_lookup` in `ArrayContains`:

 {{{
 def get_db_prep_lookup(self, value, connection):
 base_field = self.lhs.output_field.base_field
 value = [base_field.get_db_prep_value(x, connection) for x in value]
 return super().get_db_prep_lookup(value, connection)
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.f22eeb11dc97fb86019e70912744b4d0%40djangoproject.com.

Re: [Django] #30714: Add a system check against SESSION_EXPIRE_AT_BROWSER_CLOSE and SESSION_COOKIE_AGE both being set

[Django]

#30714: Add a system check against SESSION_EXPIRE_AT_BROWSER_CLOSE and
SESSION_COOKIE_AGE both being set
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  New feature  |   Status:  closed
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Yeah... still not convinced they're contraries.
 `SESSION_EXPIRE_AT_BROWSER_CLOSE` tumps whatever value you have for
 `SESSION_COOKIE_AGE`, so if you set, you meant that. I'm not at all
 convinced we need a system check here.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.ba1df380b4af8b6759f52681252ff29f%40djangoproject.com.

Re: [Django] #30714: Add a system check against SESSION_EXPIRE_AT_BROWSER_CLOSE and SESSION_COOKIE_AGE both being set

[Django]

#30714: Add a system check against SESSION_EXPIRE_AT_BROWSER_CLOSE and
SESSION_COOKIE_AGE both being set
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  New feature  |   Status:  closed
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Adam (Chainz) Johnson):

 The check can use `settings.is_overridden` to check that the user has set
 it, rather than it being the default coming from the global settings file
 :)

 I posted this ticket because it happened to me, found a project that had
 both configured and it wasn't clear which was intended by the original
 developer.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.a8ad9b7611b466d60db6a2bd2e9923c8%40djangoproject.com.

Re: [Django] #29043: test --keepdb says "Using existing test database" even if it's run for the first time

[Django]

#29043: test --keepdb says "Using existing test database" even if it's run for 
the
first time
-+-
 Reporter:  karyon   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 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 felixxm):

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


Comment:

 After evaluating proposed patches I have to say that it's not worth to add
 a complexity here.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.fe4faeab2b20ae54d4443f603eaf31ec%40djangoproject.com.

Re: [Django] #30715: ArrayField lookups crash on ArrayAgg() over AutoFields. (was: ArrayField is converting AutoField to serial[] being an invalid pSQL type)

[Django]

#30715: ArrayField lookups crash on ArrayAgg() over AutoFields.
-+-
 Reporter:  NyanKiyoshi  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  array, serial,   | Triage Stage:  Accepted
  postgres, psql, auto, id   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Thanks for the report, all `ArrayField`'s
 
[https://github.com/django/django/blob/b10d322c41f66dc7c77c36f90a3532269b25ea93/django/contrib/postgres/fields/array.py#L193-L222
 lookups] are affected, using a `Cast()` expression (that already handle
 this) instead of `'%s::%s'` should fix this issue (tests should land in
 `postgres_tests/test_array.py`).

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

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

Re: [Django] #30695: Fix an example of Storage objects in Managing files docs.

[Django]

#30695: Fix an example of Storage objects in Managing files docs.
-+-
 Reporter:  Tobias McNulty   |Owner:  Harrison
 Type:   |  Morgan
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  2.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Carlton Gibson ):

 In [changeset:"0dc3ad163a7343347af710f4e057fbdb3d0eacf4" 0dc3ad16]:
 {{{
 #!CommitTicketReference repository=""
 revision="0dc3ad163a7343347af710f4e057fbdb3d0eacf4"
 [2.2.x] Fixed #30695 -- Used relative path in default_storage docs
 example.

 Backport of 1e429df748867097451bf0b45d1080ae6828d921 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.950c877f06d784b3adb9b94c7f8f0cc8%40djangoproject.com.

Re: [Django] #30695: Fix an example of Storage objects in Managing files docs.

[Django]

#30695: Fix an example of Storage objects in Managing files docs.
-+-
 Reporter:  Tobias McNulty   |Owner:  Harrison
 Type:   |  Morgan
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  2.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"1e429df748867097451bf0b45d1080ae6828d921" 1e429df]:
 {{{
 #!CommitTicketReference repository=""
 revision="1e429df748867097451bf0b45d1080ae6828d921"
 Fixed #30695 -- Used relative path in default_storage docs example.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.ce801911ddfa45b99228956192e2cb1d%40djangoproject.com.

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 felixxm):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.b850daa2732c33673e4ef88195ef2431%40djangoproject.com.

Re: [Django] #29667: path converters don't handle spaces well.

[Django]

#29667: path converters don't handle spaces well.
-+-
 Reporter:  Keryn Knight |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  converters path  | Triage Stage:  Ready for
  _route_to_regex|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"22394bd3a18a7d9a8957a0b431f8ae4e5ca03a8c" 22394bd3]:
 {{{
 #!CommitTicketReference repository=""
 revision="22394bd3a18a7d9a8957a0b431f8ae4e5ca03a8c"
 Fixed #29667 -- Prohibited whitespaces in path() URLs.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.2ba82297e254a3903953e12db6b603c8%40djangoproject.com.

Re: [Django] #30715: ArrayField is converting AutoField to serial[] being an invalid pSQL type

[Django]

#30715: ArrayField is converting AutoField to serial[] being an invalid pSQL 
type
-+-
 Reporter:  NyanKiyoshi  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  contrib.postgres |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  array, serial,   | Triage Stage:
  postgres, psql, auto, id   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Patryk Zawadzki):

 * cc: Patryk Zawadzki (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.2ef7227870228ad1d921683288566800%40djangoproject.com.

Re: [Django] #29667: path converters don't handle spaces well.

[Django]

#29667: path converters don't handle spaces well.
-+-
 Reporter:  Keryn Knight |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  converters path  | Triage Stage:  Ready for
  _route_to_regex|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


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

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

Re: [Django] #29667: path converters don't handle spaces well.

[Django]

#29667: path converters don't handle spaces well.
-+-
 Reporter:  Keryn Knight |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  converters path  | Triage Stage:  Accepted
  _route_to_regex|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1


Comment:

 Patch looks good: just a few adjustments and ready to go. (I'll mark RFC
 to keep it on my rader: I assume Hasan will turn them around quickly, as
 ever ) Thanks Hasan!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f8a1f5b59b51dd43b798d155300a6dc8%40djangoproject.com.

[Django] #30715: ArrayField is converting AutoField to serial[] being an invalid pSQL type

[Django]

#30715: ArrayField is converting AutoField to serial[] being an invalid pSQL 
type
-+-
   Reporter: |  Owner:  (none)
  NyanKiyoshi|
   Type:  Bug| Status:  new
  Component: |Version:  2.2
  contrib.postgres   |   Keywords:  array, serial,
   Severity:  Normal |  postgres, psql, auto, id
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When doing a annotation using the `ArrayAgg()` function over the `id/pk`
 (`django.db.models.fields.AutoField`) field it is casted to `serial[]`
 which is an invalid type in pSQL.

 From this, we get the following error (caused by
 
https://github.com/django/django/blob/b10d322c41f66dc7c77c36f90a3532269b25ea93/django/contrib/postgres/fields/array.py#L81-L83):
 {{{
 psycopg2.errors.UndefinedObject: type "serial[]" does not exist
 LINE 1: ... HAVING ARRAY_AGG("item_item"."id" ) @> ARRAY[1,2]::serial[]
 }}}

 Example:
 {{{
 #!python

 from django.db import models


 class Item(models.Model):
 pass
 }}}

 {{{
 #!python

 from django.contrib.postgres.aggregates import ArrayAgg
 from django.db.models import F
 from django.test import TestCase

 from .models import Item


 class TestQueryAutoIDAsArray(TestCase):
 def test_query(self):
 qs = Item.objects.annotate(pk_list=ArrayAgg(F("id")))
 qs = qs.filter(pk_list__contains=[1, 2])
 assert len(qs[:]) == 0
 }}}

 Maybe we should cast auto fields to `int[]`?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.12d2dfd0e04c9e0865ee1fa95b3cc018%40djangoproject.com.

Re: [Django] #29979: Refactor AutoField logic into a mixin, implement checks and validators.

[Django]

#29979: Refactor AutoField logic into a mixin, implement checks and validators.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  autofield,   | Triage Stage:  Accepted
  validators |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"21e559495b8255bba1e8a4429cd083246ab90457" 21e5594]:
 {{{
 #!CommitTicketReference repository=""
 revision="21e559495b8255bba1e8a4429cd083246ab90457"
 Fixed #29979, Refs #17337 -- Extracted AutoField field logic into a mixin
 and refactored AutoFields.

 This reduces duplication by allowing AutoField, BigAutoField and
 SmallAutoField to inherit from IntegerField, BigIntegerField and
 SmallIntegerField respectively. Doing so also allows for enabling the
 max_length warning check and minimum/maximum value validation for auto
 fields, as well as providing a mixin that can be used for other possible
 future auto field types such as a theoretical UUIDAutoField.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.9a4c3a77fef47fbf62d92567fede275c%40djangoproject.com.

Re: [Django] #17337: [nonrel] Support for non-integer AutoFields

[Django]

#17337: [nonrel] Support for non-integer AutoFields
-+-
 Reporter:  Jonas H. |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  nonrel   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"21e559495b8255bba1e8a4429cd083246ab90457" 21e5594]:
 {{{
 #!CommitTicketReference repository=""
 revision="21e559495b8255bba1e8a4429cd083246ab90457"
 Fixed #29979, Refs #17337 -- Extracted AutoField field logic into a mixin
 and refactored AutoFields.

 This reduces duplication by allowing AutoField, BigAutoField and
 SmallAutoField to inherit from IntegerField, BigIntegerField and
 SmallIntegerField respectively. Doing so also allows for enabling the
 max_length warning check and minimum/maximum value validation for auto
 fields, as well as providing a mixin that can be used for other possible
 future auto field types such as a theoretical UUIDAutoField.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.3d96a72a4ec5d7287e2854c6565d2887%40djangoproject.com.

Re: [Django] #30714: Add a system check against SESSION_EXPIRE_AT_BROWSER_CLOSE and SESSION_COOKIE_AGE both being set

[Django]

#30714: Add a system check against SESSION_EXPIRE_AT_BROWSER_CLOSE and
SESSION_COOKIE_AGE both being set
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  New feature  |   Status:  closed
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 I'm not sure about this.

 `SESSION_COOKIE_AGE` defaults to two weeks. (OK, one thinks). I don't
 touch that. I simply enable `SESSION_EXPIRE_AT_BROWSER_CLOSE` and all of a
 sudden I get a warning?

 That seems less than ideal.

 Either we need to rationalize these settings somehow. (Maybe
 `SESSION_COOKIE_AGE == 0` entailing `SESSION_EXPIRE_AT_BROWSER_CLOSE`?) Or
 accept that whilst related they're not strictly interdependent.

 Happy to think about it, but a decision is needed first no? Going to say
 `wontfix` plus possible discussion on DevelopersMailingList for that
 reason. Happy to reopen later if we can come up with something.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.650c068baf0fb1fa9331324f344e211b%40djangoproject.com.