Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

gc: drop jobs tables whose table no longer exists

オープン
  • 何か問題がありますか？
#1,644 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 4 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
mysql, postgresql, python
領域
databases

調査の方向性

Start by reading dj.gc and the existing GarbageCollector.collect() implementation to understand how reports and errors are represented. Trace how schema tables identify Computed and Imported tables and how their tier prefixes map to ~~ jobs tables; the issue names no files or tests, so locate the relevant tests before implementation. Done means dry-run reports all orphaned jobs tables without changes, execution drops only those tables, and the acceptance cases pass on MySQL and PostgreSQL.

索引モデルが issue の本文から書いたものです。

説明

enhancement

Summary

A jobs table, ~~<name>, can outlive the auto-populated table it belongs to: #1601 shows it for drop(), and its comments show it for a cascading drop and for a drop through a virtual module. It also happens with tables dropped by an earlier release, by another process, or by hand. A jobs table left behind keeps its records and its primary key, and a table declared later under the same name inherits them (#1601).

Fixing drop() stops new leftovers, but not the ones already in existing schemas. A garbage-collection step would remove those too, whatever path left them, the same way dj.gc already handles orphaned objects in storage.

Proposal

A function in dj.gc, separate from GarbageCollector because jobs tables live in the database and not in a store:

dj.gc.collect_jobs_tables(schema)                 # report only (dry_run=True by default)
dj.gc.collect_jobs_tables(schema, dry_run=False)  # drop the orphans
  • For each schema, list the ~~% tables and the Computed and Imported tables. A jobs table is orphaned when no Computed or Imported table has its name, after the tier prefix is stripped (__name or _name for ~~name).
  • dry_run=True is a read-only report; dry_run=False drops the orphaned jobs tables, and nothing else.
  • Return a report in the style of GarbageCollector.collect(): the number of jobs tables found, the orphaned ones by full name, the number dropped, and errors.

Out of scope

A jobs table whose table exists but whose primary key no longer matches it, after a table is re-declared under the same name. That is the check in AutoPopulate.jobs that #1601 proposes; a GC step cannot tell a stale jobs table from a current one by name alone.

Acceptance

  • With dry_run=True nothing changes; the report lists every orphaned jobs table.
  • With dry_run=False exactly those are dropped. Jobs tables of existing Computed and Imported tables are kept, along with their records.
  • After Stage1.drop() cascades to Stage2 (the reproduction in #1601's comments), both ~~stage1 and ~~stage2 are reported and dropped.
  • Works on MySQL and on PostgreSQL.
主要言語
Python
スター
197
フォーク
101
平均マージ
3日 8時間
マージ済み PR（30日）
28

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

datajoint/datajoint-python のほかの issue

datajoint/datajoint-python の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。