Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

gc: drop jobs tables whose table no longer exists

未關閉
#1,644 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 4 天內回覆

還沒有人認領這個 Issue。

評估

難度
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 小時
30 天內合併 PR
28

環境準備

  • 提供 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

datajoint/datajoint-python 的其他 Issue

查看 datajoint/datajoint-python 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。