[Django] #29494: Flush command doesn’t work on custom db_table including schema
Django
--------------------------------------------+------------------------
Reporter: Bertrand Bordage | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 2.0
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 |
--------------------------------------------+------------------------
Suppose you have a model like this on PostgreSQL:
{{{
class SomeModel(Model):
class Meta:
db_table = '"public"."someapp_somemodel"'
}}}
Flushing has no impact on this model, which is very important in tests,
since data created in `setUp` is normally automatically removed in
`tearDown` using the `flush` command.
This is because `connection.introspection.django_table_names` is used with
the argument `only_existing=True`, which removes every name that is not
exactly yield by `connection.introspection.get_table_list`. In my example,
`only_existing=True` removes `'"public"."someapp_somemodel"'` because it
is not exactly the same as `'someapp_somemodel'`.
A solution could be to add a method that would yield full table names, and
use that method in the flush command.
Another solution can be to ammend django_table_names and manually check
against a regexp and a list of existing schemas+tables combinations…
--
Ticket URL: <https://code.djangoproject.com/ticket/29494>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Bertrand Bordage | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 2.0
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 Carlton Gibson):
* cc: Carlton Gibson (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/29494#comment:1>
Django
Reporter: Bertrand Bordage | Owner: nobody
Component: Uncategorized | Version: 2.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 Carlton Gibson):
* status: new => closed
* resolution: => duplicate
Comment:
This looks like a duplicate of #6148. (Essentially schemas aren't as yet
supported.)
See [https://code.djangoproject.com/ticket/1208#comment:6 the comment on
#1208] that suggests a possible workaround.
--
Ticket URL: <https://code.djangoproject.com/ticket/29494#comment:2>
Django
Reporter: Bertrand Bordage | Owner: nobody
Component: Uncategorized | Version: 2.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
Comment (by Carlton Gibson):
#22673 is (also) essentially the same issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/29494#comment:3>
Django
Reporter: Bertrand Bordage | Owner: nobody
Component: Database layer | Version: master
(models, ORM) |
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 Bertrand Bordage):
* type: Uncategorized => Bug
* version: 2.0 => master
* component: Uncategorized => Database layer (models, ORM)
Comment:
It’s not really true that Django doesn’t support schemas. Some work has
been done to make the `"schema"."table"` trick functional, it was not
possible previously.
And currently, using that trick works flawlessly on PostgreSQL, except
that flushing is silently not done, which can lead to critical data
issues.
Django should explicitly raise an exception when a table name contains a
schema name or a dot instead of the current misleading behaviour.
For the record, I never use these schema tricks, I just chose to support
them in django-cachalot because they seem like valid advanced uses.
Also, #1208 does not suggest a workaround to this issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/29494#comment:4>