[Django] #37317: Remove undocumented createcachetable <table_name…> support

0 views

Skip to first unread message

Django

unread,

2:29 PM (8 hours ago) 2:29 PM

to django-...@googlegroups.com

#37317: Remove undocumented createcachetable <table_name…> support
-------------------------------------+-------------------------------------
Reporter: Mike Edmunds | Type:
| Cleanup/optimization
Status: new | Component: Core
| (Management commands)
Version: 6.1 | Severity: Normal
Keywords: cache | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
The `createcachetable` management command used to accept one or more
''table_name'' command-line arguments. That behavior was removed from the
[https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-
createcachetable documentation] in 1.7 when the command was changed to
iterate over all `CACHES`, but the
[https://github.com/django/django/blob/5180f82f48b589f93cddc7be7896f654a9aec1ad/django/core/management/commands/createcachetable.py#L47-L50
implementation] is still in place with a "Legacy behavior" comment.

Retaining the undocumented legacy behavior adds maintenance burden (e.g.,
in implementing features like #36830) and creates potential confusion for
users who might try to run `createcachetable` with a `CACHES` alias rather
than a table name.

Suggest removing support for `args` in `createcachetable`, with
deprecation notices (in case there are still some scripts out there
relying on the legacy behavior).
--
Ticket URL: <https://code.djangoproject.com/ticket/37317>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,

2:30 PM (8 hours ago) 2:30 PM

to django-...@googlegroups.com

#37317: Remove undocumented createcachetable <table_name…> support
-------------------------------------+-------------------------------------

Description changed by Mike Edmunds:

Old description:

> The `createcachetable` management command used to accept one or more
> ''table_name'' command-line arguments. That behavior was removed from the
> [https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-
> createcachetable documentation] in 1.7 when the command was changed to
> iterate over all `CACHES`, but the
> [https://github.com/django/django/blob/5180f82f48b589f93cddc7be7896f654a9aec1ad/django/core/management/commands/createcachetable.py#L47-L50
> implementation] is still in place with a "Legacy behavior" comment.
>
> Retaining the undocumented legacy behavior adds maintenance burden (e.g.,
> in implementing features like #36830) and creates potential confusion for
> users who might try to run `createcachetable` with a `CACHES` alias
> rather than a table name.
>
> Suggest removing support for `args` in `createcachetable`, with
> deprecation notices (in case there are still some scripts out there
> relying on the legacy behavior).

New description:

The `createcachetable` management command used to accept one or more
''table_name'' command-line arguments. That behavior was removed from the
[https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-
createcachetable documentation] in 1.7 when the command was changed to

iterate over all `CACHES` (#15888), but the

[https://github.com/django/django/blob/5180f82f48b589f93cddc7be7896f654a9aec1ad/django/core/management/commands/createcachetable.py#L47-L50
implementation] is still in place with a "Legacy behavior" comment.

Retaining the undocumented legacy behavior adds maintenance burden (e.g.,
in implementing features like #36830) and creates potential confusion for
users who might try to run `createcachetable` with a `CACHES` alias rather
than a table name.

Suggest removing support for `args` in `createcachetable`, with
deprecation notices (in case there are still some scripts out there
relying on the legacy behavior).

--