Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

gc: drop jobs tables whose table no longer exists

Offen
  • Stimmt etwas nicht?
#1,644 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 4 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
mysql, postgresql, python
Bereich
databases

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.
Vorherrschende Sprache
Python
Sterne
197
Forks
101
Ø Merge
3 T. 8 Std.
Gemergte PRs (30 T.)
28

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus datajoint/datajoint-python

Alle Issues in datajoint/datajoint-python

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.