Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#29494 closed Bug (duplicate)

Flush command doesn’t work on custom db_table including schema

Reported by: Bertrand Bordage Owned by: nobody
Component: Database layer (models, ORM) Version: dev
Severity: Normal Keywords:
Cc: Carlton Gibson Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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…

Change History (4)

comment:1 by Carlton Gibson, 6 years ago

Cc: Carlton Gibson added

comment:2 by Carlton Gibson, 6 years ago

Resolution: duplicate
Status: newclosed

This looks like a duplicate of #6148. (Essentially schemas aren't as yet supported.)

See the comment on #1208 that suggests a possible workaround. With more detail on this StackOverflow question.

Last edited 6 years ago by Carlton Gibson (previous) (diff)

comment:3 by Carlton Gibson, 6 years ago

#22673 is (also) essentially the same issue.

comment:4 by Bertrand Bordage, 6 years ago

Component: UncategorizedDatabase layer (models, ORM)
Type: UncategorizedBug
Version: 2.0master

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.

Note: See TracTickets for help on using tickets.
Back to Top