Re: [Django] #31730: manage.py sqlsequencereset not implemented for sqlite3

[Django]

#31730: manage.py sqlsequencereset not implemented for sqlite3
-+-
 Reporter:  axil |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sql sequence reset   | Triage Stage:  Accepted
  sqlite3|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by axil):

 > In the end I think the signature of the of the sequence_reset_sql method
 should be something like (style, sequences).
 Yes, it looks strange that two similar named functions have different
 signatures and do very different things:
 {{{
 def sequence_reset_by_name_sql(self, style, sequences):
 }}}
 resets sequence to 1
 {{{
 def sequence_reset_sql(self, style, model_list):
 }}}
 fixes sequences to max(id)

-- 
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/062.c848d6a1d40a692f025b9959be54f37e%40djangoproject.com.

Re: [Django] #31730: manage.py sqlsequencereset not implemented for sqlite3

[Django]

#31730: manage.py sqlsequencereset not implemented for sqlite3
-+-
 Reporter:  axil |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sql sequence reset   | Triage Stage:  Accepted
  sqlite3|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by axil):

 The main question for me here is whether or not should
 `sequence_reset_sql` automatically cascade to the autocreated many-to-many
 tables. From its main use cases described in #31731 (and considering that
 de facto this feature does not work right now and noone is reporting any
 problems)  it looks as if it shouldn't.

-- 
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/062.443192eba29e5bf192a7590f73600775%40djangoproject.com.

Re: [Django] #31730: manage.py sqlsequencereset not implemented for sqlite3

[Django]

#31730: manage.py sqlsequencereset not implemented for sqlite3
-+-
 Reporter:  axil |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sql sequence reset   | Triage Stage:  Accepted
  sqlite3|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by axil):

 > Before any code is added here
 It might have come unnoticed but there is the code already ;)
 
https://github.com/django/django/blob/6f33f7dcf3ef20d0585bece747887c7054cf2189/django/db/backends/sqlite3/operations.py#L232-L257

 > I think that we should add backend agnostics tests for the command that
 execute the provided SQL and assert it has the desired effects.
 One of the tests that I've added
 (django/tests/backends/tests.py:SequenceResetTest.test_reset_sequence)
 looks pretty backend agnostic to me:
 
https://github.com/axil/django/blob/7de27842c038d087257ebdd8e964f8921cd68295/tests/backends/tests.py#L186-L203
 I've improved it a bit now.

 >In a following commit the logic that identifies the sequences that need
 to be reset should be moved to the command itself
 Actually of the logic identifying the sequences has already been moved to
 the django.core.commands.sqlsequencerest:
 
https://github.com/django/django/blob/6f33f7dcf3ef20d0585bece747887c7054cf2189/django/core/management/commands/sqlsequencereset.py#L17-L25
 or to be precise to `app_config.get_models(include_auto_created=True)`. By
 that reason

 > to avoid the huge amount of boilerplate repeated in the current
 PostgreSQL and Oracle DatabaseOperations implementations.
 this boilerplate can be cut in half as I suggest in #31731. In what is
 left after that yes, postgresql and oracle share the same logic and can be
 refactored, but sqlite needs a somewhat different SQL statement so I see
 little room for refactoring here.

 > That will also avoid leaking db.models abstraction to the db.backends
 ones
 Yes, my patch doesn't do that.

-- 
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/062.2144dd653e0f07e7ec6652b4e71040ff%40djangoproject.com.

Re: [Django] #31731: Dead code in the sequence_reset_sql for postgres and oracle

[Django]

#31731: Dead code in the sequence_reset_sql for postgres and oracle
-+-
 Reporter:  axil |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sql sequence reset   | Triage Stage:  Accepted
  postgres oracle|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 This should likely be included in the same PR that tackles #31730 and move
 the sequence identification logic to the command.

-- 
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/062.7786c0d2b333a04b3f3d24acb8ee7487%40djangoproject.com.

Re: [Django] #31730: manage.py sqlsequencereset not implemented for sqlite3

[Django]

#31730: manage.py sqlsequencereset not implemented for sqlite3
-+-
 Reporter:  axil |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sql sequence reset   | Triage Stage:  Accepted
  sqlite3|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * needs_better_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 TIL about the `sqlsequencereset` command!

 It seems to be barely tested

 -
 
https://github.com/django/django/blob/3152146e3abd029be2457d2e780599d399db0fe2/tests/empty_models/test_commands.py#L20
 -
 
https://github.com/django/django/blob/b9cf764be62e77b4777b3a75ec256f6209a57671/tests/bash_completion/tests.py#L81

 And not implemented on both SQLite and MySQL!

 Before any code is added here I think that we should add backend agnostics
 tests for the command that execute the provided SQL and assert it has the
 desired effects. This will likely require skipping the tests on SQLite and
 MySQL at first.

 In a following commit the logic that identifies the sequences that need to
 be reset should be moved to the command itself to avoid the huge amount of
 boilerplate repeated in the current PostgreSQL and Oracle
 `DatabaseOperations` implementations. That will also avoid leaking
 `db.models` abstraction to the `db.backends` ones. We should probably use
 `connection.introspection.sequence_list()` to ''JOIN'' its return value to
 the specified model subset tables. In the end I think the signature of the
 of the `sequence_reset_sql` method should be something like `(style,
 sequences)`.

 Then we should be able to add support for both SQLite and MySQL.

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

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

Re: [Django] #31670: Change "whitelist" to "allow list" and "blacklist" to "deny list".

[Django]

#31670: Change "whitelist" to "allow list" and "blacklist" to "deny list".
-+-
 Reporter:  Adam (Chainz)|Owner:  David
  Johnson|  Smith
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Alexander Ovchinnikov):

 I am [as part of the Django user community] don’t give a damn about the
 black skin community members, gays, women, cats and puppies etc. I'm sorry
 for that.

 Their troubles are their troubles, not my. Django project is not about
 saving world or humanity or black people.

 You may follow #BlackLivesMatter or #AllLivesMatter or anything like that
 in your free time for you personal projects, why not.

 I'm not a racist etc. I just do not want to spend even 1 minute of my time
 for solving that troubles. It's none of my business.

 You renamed something in Django. For all of us. It mean, every Django user
 now will spend their time during upgrade. Tank you for that.

 I hope that I did not offend anyone with my opinion.

-- 
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.e2fc3804c6eaa456575421e8f1291632%40djangoproject.com.

Re: [Django] #31731: Dead code in the sequence_reset_sql for postgres and oracle

[Django]

#31731: Dead code in the sequence_reset_sql for postgres and oracle
-+-
 Reporter:  axil |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sql sequence reset   | Triage Stage:
  postgres oracle|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by axil:

Old description:

> In the definition of `sequence_reset_sql` function in
> `django/db/backends/postgresql/operations.py` and
> `django/db/backends/oracle/operations.py` files
>
> {{{
>def sequence_reset_sql(self, style, model_list):
>from django.db import models
>output = []
>qn = self.quote_name
>
>for model in model_list:
> # Use `coalesce` to set the sequence for each model to the
> max pk value if there are records,
> # or 1 if there are none. Set the `is_called` property (the
> third argument to `setval`) to true
> # if there are records (as the max pk value is already in
> use), otherwise set it to false.
> # Use pg_get_serial_sequence to get the underlying sequence
> name from the table name
> # and column name (available since PostgreSQL 8)
>
> for f in model._meta.local_fields:
> if isinstance(f, models.AutoField):
> output.append(
> "%s setval(pg_get_serial_sequence('%s','%s'), "
> "coalesce(max(%s), 1), max(%s) %s null) %s %s;" %
> (
> style.SQL_KEYWORD('SELECT'),
> style.SQL_TABLE(qn(model._meta.db_table)),
> style.SQL_FIELD(f.column),
> style.SQL_FIELD(qn(f.column)),
> style.SQL_FIELD(qn(f.column)),
> style.SQL_KEYWORD('IS NOT'),
> style.SQL_KEYWORD('FROM'),
> style.SQL_TABLE(qn(model._meta.db_table)),
> )
> )
> break  # Only one AutoField is allowed per model, so
> don't bother continuing.
> for f in model._meta.many_to_many:
> if not f.remote_field.through:
> ##output.append(
> ##   "%s setval(pg_get_serial_sequence('%s','%s'), "
> ##"coalesce(max(%s), 1), max(%s) %s null) %s %s;"
> % (
> ##   style.SQL_KEYWORD('SELECT'),
> ##style.SQL_TABLE(qn(f.m2m_db_table())),
> ##style.SQL_FIELD('id'),
> ##style.SQL_FIELD(qn('id')),
> ##style.SQL_FIELD(qn('id')),
> ##style.SQL_KEYWORD('IS NOT'),
> ##style.SQL_KEYWORD('FROM'),
> ##style.SQL_TABLE(qn(f.m2m_db_table()))
> ##)
> ##)
> return output
> }}}
>
> The statement marked with ## never executes.
>
> 11 years ago when this code was written (ticket #11107) this `if not
> f.remote_field.through:` was a valid way to check if the
> `ManyToManyField` uses the user-provided intermediate `through` table or
> not. Nowadays `bool(f.remote_field.through)` always evaluates to `True`,
> no matter if it is a user-provided or an automatic table.
>
> But actually it is not necessary anymore. This function is used in three
> places in django code:
>
> 1) `manage.py sqlsequencereset` uses
> {{{
> models = app_config.get_models(include_auto_created=True)
> }}}
> instead of the original
> {{{
> models = app_config.get_models()
> }}}
> which was there when this ticket 11107 was merged. So now it fetches both
> automatic and user-defined intermediate tables at the ealier stage,
> before going.
>
> 2) loaddata is unaffected by this branch of execution because it needs to
> reset the sequences solely of the models that are being loaded and not of
> any others. To be 100% sure I included the fixture from ticket 11107 as
> the testcase and it passes without entering into that execution branch.
>
> 3) `django.contrib.sites.management.create_default_site` applies it to
> the Site model
> {{{
> sequence_sql = connections[using].ops.sequence_reset_sql(no_style(),
> [Site])
> }}}
> which has no manytomany keys, so it is unaffected.
>
> I would suggest to remove the code marked with 

Re: [Django] #31730: manage.py sqlsequencereset not implemented for sqlite3

[Django]

#31730: manage.py sqlsequencereset not implemented for sqlite3
-+-
 Reporter:  axil |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sql sequence reset   | Triage Stage:
  sqlite3|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by axil:

Old description:

> Currently `./manage.py sqlsequencereset`
> ([https://docs.djangoproject.com/en/3.0/ref/django-
> admin/#sqlsequencereset docs]) never prints anything for the sqlite3
> backend.
>
> It happens because the function `sequence_reset_sql` defined in
> `django/django/db/backends/base/operations.py`
> is not implemented for the sqlite3 backend in
> `django/django/db/backends/sqlite3/operations.py`
>
> `django/django/contrib/sites/management.py` makes use of this function
>
> {{{
> # We set an explicit pk instead of relying on auto-incrementation,
> # so we need to reset the database sequence. See #17415.
> sequence_sql = connections[using].ops.sequence_reset_sql(no_style(),
> [Site])
> if sequence_sql:
> if verbosity >= 2:
>  print("Resetting sequence")
> }}}
>
> Here `sequence_reset_sql` also does nothing for sqlite3, but sqlite3 is
> pretty lenient to
> the sequences, so it didn't result in an exception.
>
> Same applies to its usage in `manage.py loaddata`: sqlite3 fixes the
> sequences automatically.
>
> What it cannot do automatically is reset the sequence to zero as
> demonstrated in the new test
> `django/tests/backends/tests.py:SequenceResetTest.test_reset_sequence`
>
> {{{
> def test_reset_sequence(self):
> Post.objects.create(name='1st post', text='hello world')
>
> Post.objects.all().delete()
>
> # Reset the sequences for the database
> commands =
> connections[DEFAULT_DB_ALIAS].ops.sequence_reset_sql(no_style(), [Post])
> with connection.cursor() as cursor:
> for sql in commands:
> cursor.execute(sql)
>
> # If we create a new object now, it should have a PK greater
> # than the PK we specified manually.
> obj = Post.objects.create(name='New post', text='goodbye world')
> self.assertEqual(obj.pk, 1)
> }}}

New description:

 Currently `./manage.py sqlsequencereset`
 ([https://docs.djangoproject.com/en/3.0/ref/django-admin/#sqlsequencereset
 docs]) never prints anything for the sqlite3 backend.

 It happens because the function `sequence_reset_sql` defined in
 `django/django/db/backends/base/operations.py`
 is not implemented for the sqlite3 backend in
 `django/django/db/backends/sqlite3/operations.py`

 `django/django/contrib/sites/management.py` makes use of this function

 {{{
 # We set an explicit pk instead of relying on auto-incrementation,
 # so we need to reset the database sequence. See #17415.
 sequence_sql = connections[using].ops.sequence_reset_sql(no_style(),
 [Site])
 if sequence_sql:
 if verbosity >= 2:
  print("Resetting sequence")
 }}}

 Here `sequence_reset_sql` also does nothing for sqlite3, but sqlite3 is
 pretty lenient to
 the sequences, so it didn't result in an exception.

 Same applies to its usage in `manage.py loaddata`: sqlite3 fixes the
 sequences automatically.

 Leniency of sqlite is also the explanation of how
 `django/tests/backends/tests.py:SequenceResetTest.test_generic_relation`
 test contrives to pass with `sequence_reset_sql` being noop for sqlite3.

 What it cannot do automatically is reset the sequence to zero as
 demonstrated in the new test
 `django/tests/backends/tests.py:SequenceResetTest.test_reset_sequence`

 {{{
 def test_reset_sequence(self):
 Post.objects.create(name='1st post', text='hello world')

 Post.objects.all().delete()

 # Reset the sequences for the database
 commands =
 connections[DEFAULT_DB_ALIAS].ops.sequence_reset_sql(no_style(), [Post])
 with connection.cursor() as cursor:
 for sql in commands:
 cursor.execute(sql)

 # If we create a new object now, it should have a PK greater
 # than the PK we specified manually.
 obj = Post.objects.create(name='New post', text='goodbye world')
 self.assertEqual(obj.pk, 1)
 }}}

--

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

[Django] #31731: Dead code in the sequence_reset_sql for postgres and oracle

[Django]

#31731: Dead code in the sequence_reset_sql for postgres and oracle
-+-
   Reporter:  axil   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.0
  layer (models, ORM)|   Keywords:  sql sequence reset
   Severity:  Normal |  postgres oracle
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In the definition of `sequence_reset_sql` function in
 `django/db/backends/postgresql/operations.py` and
 `django/db/backends/oracle/operations.py` files

 {{{
def sequence_reset_sql(self, style, model_list):
from django.db import models
output = []
qn = self.quote_name

for model in model_list:
 # Use `coalesce` to set the sequence for each model to the max
 pk value if there are records,
 # or 1 if there are none. Set the `is_called` property (the
 third argument to `setval`) to true
 # if there are records (as the max pk value is already in
 use), otherwise set it to false.
 # Use pg_get_serial_sequence to get the underlying sequence
 name from the table name
 # and column name (available since PostgreSQL 8)

 for f in model._meta.local_fields:
 if isinstance(f, models.AutoField):
 output.append(
 "%s setval(pg_get_serial_sequence('%s','%s'), "
 "coalesce(max(%s), 1), max(%s) %s null) %s %s;" %
 (
 style.SQL_KEYWORD('SELECT'),
 style.SQL_TABLE(qn(model._meta.db_table)),
 style.SQL_FIELD(f.column),
 style.SQL_FIELD(qn(f.column)),
 style.SQL_FIELD(qn(f.column)),
 style.SQL_KEYWORD('IS NOT'),
 style.SQL_KEYWORD('FROM'),
 style.SQL_TABLE(qn(model._meta.db_table)),
 )
 )
 break  # Only one AutoField is allowed per model, so
 don't bother continuing.
 for f in model._meta.many_to_many:
 if not f.remote_field.through:
 ##output.append(
 ##   "%s setval(pg_get_serial_sequence('%s','%s'), "
 ##"coalesce(max(%s), 1), max(%s) %s null) %s %s;"
 % (
 ##   style.SQL_KEYWORD('SELECT'),
 ##style.SQL_TABLE(qn(f.m2m_db_table())),
 ##style.SQL_FIELD('id'),
 ##style.SQL_FIELD(qn('id')),
 ##style.SQL_FIELD(qn('id')),
 ##style.SQL_KEYWORD('IS NOT'),
 ##style.SQL_KEYWORD('FROM'),
 ##style.SQL_TABLE(qn(f.m2m_db_table()))
 ##)
 ##)
 return output
 }}}

 The statement marked with ## never executes.

 11 years ago when this code was written (ticket #11107) this `if not
 f.remote_field.through:` was a valid way to check if the `ManyToManyField`
 uses the user-provided intermediate `through` table or not. Nowadays
 `bool(f.remote_field.through)` always evaluates to `True`, no matter if it
 is a user-provided or an automatic table.

 But actually it is not necessary anymore. This function is used in three
 places in django code:

 1) `manage.py sqlsequencereset` uses
 {{{
 models = app_config.get_models(include_auto_created=True)
 }}}
 instead of the original
 {{{
 models = app_config.get_models()
 }}}
 which was there when this ticket 11107 was merged. So now it fetches both
 automatic and user-defined intermediate tables at the ealier stage, before
 going.

 2) loaddata is unaffected by this branch of execution because it needs to
 reset the sequences solely of the models that are being loaded and not of
 any others. To be 100% sure I included the fixture from ticket 11107 as
 the testcase and it passes without entering into that execution branch.

 3) `django.contrib.sites.management.create_default_site` applies it to the
 Site model
 {{{
 sequence_sql = connections[using].ops.sequence_reset_sql(no_style(),
 [Site])
 }}}
 which has no manytomany keys, so it is unaffected.

 I would suggest to remove the code marked with "##" and check for other
 usages of `f.remote_field.through` for similar issues.

-- 
Ticket URL: 
Django 
The Web framework for perfect

Re: [Django] #31730: manage.py sqlsequencereset not implemented for sqlite3

[Django]

#31730: manage.py sqlsequencereset not implemented for sqlite3
-+-
 Reporter:  axil |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sql sequence reset   | Triage Stage:
  sqlite3|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by axil):

 The fix is related and partly based on the code from the recent ticket
 #31479 as well as on the corresponding functions for postgres and oracle.

-- 
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/062.6fb6068803dd53c7054376a4532e6045%40djangoproject.com.

Re: [Django] #31730: manage.py sqlsequencereset not implemented for sqlite3

[Django]

#31730: manage.py sqlsequencereset not implemented for sqlite3
-+-
 Reporter:  axil |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sql sequence reset   | Triage Stage:
  sqlite3|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by axil):

 https://github.com/django/django/pull/13093

-- 
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/062.043baf1313c3c1135f9e24920caeddd5%40djangoproject.com.

[Django] #31730: manage.py sqlsequencereset not implemented for sqlite3

[Django]

#31730: manage.py sqlsequencereset not implemented for sqlite3
-+-
   Reporter:  axil   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.0
  layer (models, ORM)|   Keywords:  sql sequence reset
   Severity:  Normal |  sqlite3
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Currently `./manage.py sqlsequencereset`
 ([https://docs.djangoproject.com/en/3.0/ref/django-admin/#sqlsequencereset
 docs]) never prints anything for the sqlite3 backend.

 It happens because the function `sequence_reset_sql` defined in
 `django/django/db/backends/base/operations.py`
 is not implemented for the sqlite3 backend in
 `django/django/db/backends/sqlite3/operations.py`

 `django/django/contrib/sites/management.py` makes use of this function

 {{{
 # We set an explicit pk instead of relying on auto-incrementation,
 # so we need to reset the database sequence. See #17415.
 sequence_sql = connections[using].ops.sequence_reset_sql(no_style(),
 [Site])
 if sequence_sql:
 if verbosity >= 2:
  print("Resetting sequence")
 }}}

 Here `sequence_reset_sql` also does nothing for sqlite3, but sqlite3 is
 pretty lenient to
 the sequences, so it didn't result in an exception.

 Same applies to its usage in `manage.py loaddata`: sqlite3 fixes the
 sequences automatically.

 What it cannot do automatically is reset the sequence to zero as
 demonstrated in the new test
 `django/tests/backends/tests.py:SequenceResetTest.test_reset_sequence`

 {{{
 def test_reset_sequence(self):
 Post.objects.create(name='1st post', text='hello world')

 Post.objects.all().delete()

 # Reset the sequences for the database
 commands =
 connections[DEFAULT_DB_ALIAS].ops.sequence_reset_sql(no_style(), [Post])
 with connection.cursor() as cursor:
 for sql in commands:
 cursor.execute(sql)

 # If we create a new object now, it should have a PK greater
 # than the PK we specified manually.
 obj = Post.objects.create(name='New post', text='goodbye world')
 self.assertEqual(obj.pk, 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/047.2d5a6745ad940194610ddd873d59b97a%40djangoproject.com.

Re: [Django] #9061: formsets with can_delete=True shouldn't add delete field to extra forms

[Django]

#9061: formsets with can_delete=True shouldn't add delete field to extra forms
-+---
 Reporter:  Gabriel Farrell  |Owner:  David Smith
 Type:  New feature  |   Status:  assigned
Component:  Forms|  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 David Smith):

 * owner:  Daniel Ward => David Smith


-- 
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/061.7d2acce57f2089397ba364b12b8a9845%40djangoproject.com.

Re: [Django] #31723: Lag() with DecimalField crashes on SQLite.

[Django]

#31723: Lag() with DecimalField crashes on SQLite.
-+-
 Reporter:  qwango   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Lag  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Likely an issue due to `SQLiteNumericMixin`
 
https://github.com/django/django/blob/27c09043da52ca1f02605bf28600bfd5ace95ae4/django/db/models/expressions.py#L16-L28

 We could make `Window` inherit from `SQLiteNumericMixin` and make
 `SQLiteNumericMixin.as_sqlite` a noop when `getattr(self,
 'window_compatible', False)`.

 An alternative would be to make `Window` inherit from `SQLiteNumericMixin`
 and make its `as_sqlite` special case itself when
 `isinstance(self.output_field, 'DecimalField')` with something along

 {{{#!python
 def as_sqlite(self, compiler, connection):
 if isinstance(self.output_field, 'DecimalField'):
 copy = self.copy()
 source_expressions = copy.get_source_expressions()
 source_expressions[0].output_field = FloatField()
 copy.set_source_expressions(source_expressions)
 return super(Window, copy).as_sqlite(compiler, connection)
 return self.as_sql(compiler, connection)
 }}}

 That would avoid teaching `SQLiteNumericMixin` about window functions and
 make sure window compatible functions can be used outside of windows
 expressions while being wrapped appropriately.

-- 
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.3148a7d6e751bda19e09f89766784010%40djangoproject.com.

Re: [Django] #31728: cache.backends.db._cull sometimes fails with 'NoneType' object is not subscriptable

[Django]

#31728: cache.backends.db._cull sometimes fails with 'NoneType' object is not
subscriptable
-+
 Reporter:  Guillermo Bonvehí|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  cache db | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by Simon Charette):

 * needs_better_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report and patch. Left some comments for improvements to
 make the test backend agnostic, once they are addressed feel free to
 uncheck the _Patch needs improvement_ flag for your patch to show up in
 the review queue.

-- 
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.9186bc1b42c2dfc560fc1627857efb95%40djangoproject.com.

Re: [Django] #31729: The documentation for ArchiveIndexView is not clear for new developers. (was: The documentation for ArchiveIndexView is not clear for new developers)

[Django]

#31729: The documentation for ArchiveIndexView is not clear for new developers.
+--
 Reporter:  Kenneth Prabakaran  |Owner:  nobody
 Type:  Uncategorized   |   Status:  closed
Component:  Documentation   |  Version:  3.0
 Severity:  Normal  |   Resolution:  invalid
 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 felixxm):

 * status:  new => closed
 * resolution:   => invalid
 * component:  Uncategorized => Documentation


Old description:

> path('archive/',
>  ArchiveIndexView.as_view(model=Article, date_field="pub_date"),
>  name="article_archive"),
>
> where the only mentioned parameters are model and pub_date, and the name
> for the template. But using this above code does lead to an error saying
> template not found. Where the main problem is we are supposed to
>
> path('archive/',
>  ArchiveIndexView.as_view(model=Article, date_field="pub_date",
> template_name="article_archive.html"),
>  ),
>
> mention the template_name as paramter for the as_view function. I know it
> might be silly to just look into the class and find the attribute
> "template_name" but for new comers trying to implement this might think
> they made a mistake somewhere else since the path was taking in the name
> of the template.
> So please do mention in the documentation

New description:

 {{{
 path('archive/',
  ArchiveIndexView.as_view(model=Article, date_field="pub_date"),
  name="article_archive"),
 }}}
 where the only mentioned parameters are model and pub_date, and the name
 for the template. But using this above code does lead to an error saying
 template not found. Where the main problem is we are supposed to
 {{{
 path('archive/',
  ArchiveIndexView.as_view(model=Article, date_field="pub_date",
 template_name="article_archive.html"),
  ),
 }}}
 mention the template_name as paramter for the as_view function. I know it
 might be silly to just look into the class and find the attribute
 "template_name" but for new comers trying to implement this might think
 they made a mistake somewhere else since the path was taking in the name
 of the template.
 So please do mention in the documentation

--

Comment:

 `template_name` is not necessary in
 [https://docs.djangoproject.com/en/dev/ref/class-based-views/generic-date-
 based/#archiveindexview this example], the inferred template will be
 "myapp/article_archive.html" that's why it's mentioned in docs. See
 [https://docs.djangoproject.com/en/dev/topics/class-based-views/generic-
 display/#generic-views-of-objects note in "Generic views of objects"
 docs].

 [https://docs.djangoproject.com/en/dev/ref/class-based-views/ "Built-in
 class-based views API" docs] is advanced docs and we shouldn't assume
 templates localization here (e.g. by changing to
 `myapp/templates/myapp/article_archive.html`,) that's why using an
 inferred template names is IMO the best option.

-- 
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.c887ef0e9ec41f216773f122ce7f7332%40djangoproject.com.

Re: [Django] #31726: Allow calculated field on admin change_list

[Django]

#31726: Allow calculated field on admin change_list
---+--
 Reporter:  pandichef  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Simon Charette):

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


Comment:

 The Django admin already supports that through `readonly_fields`.

 
https://docs.djangoproject.com/en/3.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.readonly_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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.43af7c59ceb5c24ec289aba975cd1231%40djangoproject.com.

Re: [Django] #31721: The function modelform_factory does not consider the formfield_callback of the form that it recieves as argument

[Django]

#31721: The function modelform_factory does not consider the formfield_callback 
of
the form that it recieves as argument
---+--
 Reporter:  Klaas-Jan Gorter   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Forms  |  Version:  2.2
 Severity:  Normal |   Resolution:
 Keywords:  modelform_factory  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Simon Charette):

 * cc: Claude Paroz (added)
 * type:  Bug => New feature


Comment:

 I was always the impression that `formfield_callback` was solely an
 allowed kwarg of the `modelform_factory` function and its friends.

 > I believe this test has been removed from version 2, because I find no
 equivalent test in tests/model_formsets_regress.

 From what I can see the patch from #18573 was never committed and thus
 nothing was actually removed over the years.

 Given
 
[https://github.com/django/django/blob/3b1cb78063466e996cbb042e44aadfac30df73fa/tests/model_forms/tests.py#L2820
 no tests exists for this behavior] and that
 [https://docs.djangoproject.com/en/3.0/search/?q=formfield_callback it's
 not documented] I'll change this bug report to a feature request. That
 seems like a really niche use case but since I don't use Django forms much
 myself nowadays I'll let other folks chime in.

-- 
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.d9be1753f630b5b69a4cf4c10a4c55a7%40djangoproject.com.

Re: [Django] #31720: Better documentation and defaults for BoolOr and BoolAnd

[Django]

#31720: Better documentation and defaults for BoolOr and BoolAnd
-+-
 Reporter:  Alex Scott   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * owner:  (none) => nobody
 * needs_docs:  0 => 1
 * type:  Uncategorized => Cleanup/optimization
 * component:  contrib.postgres => Database layer (models, ORM)
 * stage:  Unreviewed => Accepted


Comment:

 A patch for both documentation and explicit `output_field` for `BoolOr`
 and `BoolAnd` would be welcome. The issue you're experiencing here is
 likely due to the fact `Q` and `WhereNode` are marked `conditional=True`
 but don't set `output_field = models.BooleanField()` and thus the default
 behavior of `Expression._resolve_output_field` cannot be leveraged.

 Are you interested in submitting a PR with these improvements?

-- 
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.88c59c454eb21c8fdbc414a933e35cf1%40djangoproject.com.

[Django] #31729: The documentation for ArchiveIndexView is not clear for new developers

[Django]

#31729: The documentation for ArchiveIndexView is not clear for new developers
--+
   Reporter:  Kenneth Prabakaran  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |Version:  3.0
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+
 path('archive/',
  ArchiveIndexView.as_view(model=Article, date_field="pub_date"),
  name="article_archive"),

 where the only mentioned parameters are model and pub_date, and the name
 for the template. But using this above code does lead to an error saying
 template not found. Where the main problem is we are supposed to

 path('archive/',
  ArchiveIndexView.as_view(model=Article, date_field="pub_date",
 template_name="article_archive.html"),
  ),

 mention the template_name as paramter for the as_view function. I know it
 might be silly to just look into the class and find the attribute
 "template_name" but for new comers trying to implement this might think
 they made a mistake somewhere else since the path was taking in the name
 of the template.
 So please do mention in the documentation

-- 
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/049.57bf3f13677ddeb942554b204a95e906%40djangoproject.com.

Re: [Django] #31724: django.urls.resolve ignores the FORCE_SCRIPT_NAME setting.

[Django]

#31724: django.urls.resolve ignores the FORCE_SCRIPT_NAME setting.
---+--
 Reporter:  Pēteris Caune  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Core (URLs)|  Version:  3.0
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Florian Apolloner):

 * resolution:  duplicate => invalid


Comment:

 Thank you for the CC, I disagree on the `duplicate` state though and will
 reresolve it as `invalid`.

 I think that for this issue `FORCE_SCRIPT_NAME` works as documented and
 designed. The example wrongly assumes that `resolve` & `reverse` are able
 to round-trip like that. This is simply not the case: `resolve` does not
 operate on full URLs, but on `PATH_INFO` --
 
https://github.com/django/django/blob/27c09043da52ca1f02605bf28600bfd5ace95ae4/django/core/handlers/base.py#L288
 . So assuming your webserver is configured to serve Django under `/foo/`
 and you access `/foo/docs/` in the browser, the actual URL that Django
 sees to resolve the view is `/docs/`. It is able to do so because the
 webserver did configure `SCRIPT_NAME` as `/foo/` effectively telling
 Django that only the part after it (ie `PATH_INFO`) is relevant. But to
 `reverse` a URL properly Django does need to prepend the `SCRIPT_NAME` (or
 `FORCE_SCRIPT_NAME` for that matter).

 All in all `FORCE_SCRIPT_NAME` serves two specific purposes:

  * If your webserver configuration is broken, `FORCE_SCRIPT_NAME` can be
 used to correct the value of `SCRIPT_NAME` (though generally that might
 cause wrong `PATH_INFO` as well, so I wouldn't really recommend it in this
 scenario and try to fix the webserver).

  * If you need to generate URLs to your views outside of a request
 context. That is for example a cron job that runs without a WSGI
 environment (so `SCRIPT_NAME` is never set) and the generated URL would
 miss the prefix. In this case you will need to set `FORCE_SCRIPT_NAME` to
 the actual `SCRIPT_NAME` that your webserver would report, so Django knows
 about it in management commands etc… Under normal operations (ie when
 serving views) the webserver is able to provide that information on it's
 own.

-- 
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.d0f3623ad867c4e8c56a837c8d5d815f%40djangoproject.com.

Re: [Django] #31724: django.urls.resolve ignores the FORCE_SCRIPT_NAME setting. (was: django.urls.resolve ignores the FORCE_SCRIPT_NAME setting)

[Django]

#31724: django.urls.resolve ignores the FORCE_SCRIPT_NAME setting.
---+--
 Reporter:  Pēteris Caune  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Core (URLs)|  Version:  3.0
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by felixxm):

 * cc: Florian Apolloner (added)
 * status:  new => closed
 * type:  Uncategorized => Bug
 * resolution:   => duplicate


Comment:

 I'm pretty sure that's a duplicate of #7930, `resolve()/reserve()` is
 behavior is discussed there.

-- 
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.3d9576b9c56d200d17d669920ccf459f%40djangoproject.com.

Re: [Django] #31723: Lag() with DecimalField crashes on SQLite. (was: Using Lag function with SQLite on a DecimalField results in a SQL error)

[Django]

#31723: Lag() with DecimalField crashes on SQLite.
-+-
 Reporter:  qwango   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Lag  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * cc: Mads Jensen (added)
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for this report. I can also confirm that it works properly with
 `FloatField()`.

 Reproduced at 27c09043da52ca1f02605bf28600bfd5ace95ae4.

-- 
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.a70df10438230a3155df20dfcf5ee5d2%40djangoproject.com.

Re: [Django] #31727: Open ID Connect Support

[Django]

#31727: Open ID Connect Support
--+--
 Reporter:  pandichef |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:  duplicate
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by felixxm):

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


Comment:

 Duplicate of #3213.

-- 
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.07d3e732018e4288d01b84669a2c2c96%40djangoproject.com.

Re: [Django] #31728: cache.backends.db._cull sometimes fails with 'NoneType' object is not subscriptable

[Django]

#31728: cache.backends.db._cull sometimes fails with 'NoneType' object is not
subscriptable
-+-
 Reporter:  Guillermo Bonvehí|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  cache db | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Guillermo Bonvehí):

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

Re: [Django] #31728: cache.backends.db._cull sometimes fails with 'NoneType' object is not subscriptable

[Django]

#31728: cache.backends.db._cull sometimes fails with 'NoneType' object is not
subscriptable
-+-
 Reporter:  Guillermo Bonvehí|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  cache db | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Guillermo Bonvehí):

 Added PR https://github.com/django/django/pull/13089 from branch
 https://github.com/knixeur/django/tree/ticket_31728

-- 
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.489b2295d24b0929d99f24faaaba1a1b%40djangoproject.com.