Repository navigation
fix(drop): drop an auto-populated table's jobs table with it - #1615
dimitri-yatsenko wants to merge 1 commit into
Conversation
Sorry, something went wrong.
drop_quick() dropped only the table itself, so drop() left an auto-populated table's jobs table, ~~<table_name>, in place with its records and its primary key. A table later declared under the same name picked it up through its jobs property. When the new primary key was wider, populate(reserve_jobs=True) computed nothing and raised nothing: the old records, keyed on part of the new primary key, covered every new key. drop_quick() now drops the jobs table of a Computed or Imported table after the table itself. drop() reaches each table as a FreeTable, so the tier is read from the table name, as Schema.jobs does. A Manual or Lookup table never drops a jobs table, though a Manual `result` and a Computed `__result` map to the same `~~result`. The jobs table is itself dropped through drop_quick(), so its ~lineage rows and, on PostgreSQL, its enum type go with it. Jobs tables left by earlier releases remain, so the jobs property now checks an existing jobs table's primary key against the one it would be declared with, and raises if they differ, naming the jobs table and the command that removes it. Job computes its foreign-key-derived primary key once, so a table with a primary key attribute of its own still logs the "Ignoring non-FK primary key attribute" warning once per access. The tests run on MySQL and PostgreSQL. In the issue's reproduction, drop() removes ~~result and its lineage rows, and the table declared again with a wider primary key populates all six keys. drop_quick() removes ~~result too, with its enum type on PostgreSQL. Dropping a Manual table leaves the Computed table's ~~result in place. A jobs table left behind by a plain DROP TABLE makes jobs raise; the command in the message removes it, and populate then completes. A table with a primary key attribute of its own passes the check and warns once. Closes #1601.
|
Holding this as a draft: on PostgreSQL it would make an existing data-loss bug much more likely. drop_quick() drops a table's enum types with DROP TYPE ... CASCADE. Enum types are named by their values and shared across a schema, so the CASCADE also drops every other column that uses the same enum, with its data. Every jobs table's status column has the same enum, so with this PR, dropping one auto-populated table also drops status from every other jobs table in the schema. Checked on PostgreSQL: after A.drop(), ~~b has no status column. The enum fix goes in first, in its own PR; this one goes back to review after that. |
Sorry, something went wrong.
|
Moved to 2.4, to be designed together with #1644 (dj.gc.collect_jobs_tables). Both the stale-jobs-table check in AutoPopulate.jobs and the removal of jobs tables in drop_quick() wait for that design. It still depends on #1632 for PostgreSQL. The backport, #1616, is closed. |
Sorry, something went wrong.
This branch has not been deployed
Reviewers
At least 1 approving review is required to merge this pull request.
drop_quick() dropped only the table itself, so drop() left an
auto-populated table's jobs table, ~~<table_name>, in place with its
records and its primary key. A table later declared under the same name
picked it up through its jobs property. When the new primary key was
wider, populate(reserve_jobs=True) computed nothing and raised nothing:
the old records, keyed on part of the new primary key, covered every new
key.
drop_quick() now drops the jobs table of a Computed or Imported table
after the table itself. drop() reaches each table as a FreeTable, so the
tier is read from the table name, as Schema.jobs does. A Manual or Lookup
table never drops a jobs table, though a Manual result and a Computed
__result map to the same ~~result. The jobs table is itself dropped
through drop_quick(), so its ~lineage rows and, on PostgreSQL, its enum
type go with it.
Jobs tables left by earlier releases remain, so the jobs property now
checks an existing jobs table's primary key against the one it would be
declared with, and raises if they differ, naming the jobs table and the
command that removes it. Job computes its foreign-key-derived primary key
once, so a table with a primary key attribute of its own still logs the
"Ignoring non-FK primary key attribute" warning once per access.
The tests run on MySQL and PostgreSQL. In the issue's reproduction,
drop() removes ~~result and its lineage rows, and the table declared
again with a wider primary key populates all six keys. drop_quick()
removes ~~result too, with its enum type on PostgreSQL. Dropping a Manual
table leaves the Computed table's ~~result in place. A jobs table left
behind by a plain DROP TABLE makes jobs raise; the command in the message
removes it, and populate then completes. A table with a primary key
attribute of its own passes the check and warns once.
Closes #1601.