Rename the table tiers to a consistent axis — `dj.Entry`, `dj.Ingest`, `dj.Compute` (keep `Manual`/`Imported`/`Computed` as permanent aliases)

[dimitri-yatsenko]

Full tier rename proposed in datajoint/datajoint-docs#267. Filing the class-name change here; the terminology decision is tracked in datajoint-company/dj-brand#34.

Why

The populated tiers sit on inconsistent axes: Manual names the writer, Imported names the origin, Computed names the result. A reader reasoning from the names alone lands in the wrong tier — the classic failure being an Imported table with no make() and a permanent allow_direct_insert=True papering over a real modeling error. Putting every populated tier on one axis — what the table does to get its rows — and naming it with that verb removes the confusion.

The rename

Today	New primary name	The table's rows…
dj.Manual	dj.Entry	enter the pipeline from outside (a person, an instrument, an ingestion script) — inserted directly, no make()
dj.Imported	dj.Ingest	are produced by make() that reads an external source
dj.Computed	dj.Compute	are produced by make() that derives from other DataJoint tables

dj.Lookup and dj.Part are unchanged.

Compatibility

• dj.Manual, dj.Imported, and dj.Computed remain permanently as backward-compatible aliases — no deprecation, no migration. Existing pipelines, tutorials, and stored tier prefixes keep working; new material teaches the new names.
• Verify the SQL tier prefix, dj.config/Role, lookup_class_name, and every tier-detection path treat each alias identically to its new name (same prefix, same reserved status) so the aliases are fully transparent on existing schemas.

Why Compute, not Derive

Derive collides with an entrenched database meaning: a derived table / derived relation is the result of a query (a subquery or view), computed on read and not stored — the opposite of a Compute table, whose rows are materialized by make() and persisted with lineage. Database-literate readers would mis-read Derive as "a view." Compute also aligns with how we frame DataJoint — a computational database. (Full discussion in datajoint-docs#267.)

Naming-form note

Entry is a noun; Ingest/Compute are verbs. Python class names read as nouns (class TuningCurve(dj.Compute):), so the verb tiers carry a short adoption cost — an ergonomics tradeoff, not a correctness objection (raised by @gtouloumes in #267). Worth reinforcing the new names consistently across the docs when adopted.

Rollout (2.3.3 → 2.4.0)

Additive and backward-compatible throughout — no deprecation at any point.

• 2.3.3 — add the names (non-breaking). Introduce dj.Entry, dj.Ingest, and dj.Compute as aliases resolving to the existing tiers, so old and new names produce identical tables (same SQL prefix, same Role). No change to defaults, repr, or what the docs teach yet. Early adopters and new examples can use the names immediately with zero migration. Land the alias-transparency checks (prefix / Role / lookup_class_name / tier detection) in this release.
• 2.4.0 — make them canonical. Promote the new names to primary: repr/introspection, error messages, and dj.Diagram tier labels emit Entry/Ingest/Compute; the docs and tutorials teach them by default (with the datajoint-docs#267 axis explanation and a terminology sweep shipping alongside). dj.Manual/dj.Imported/dj.Computed remain permanent aliases — kept indefinitely, never deprecated.

Related

• datajoint-docs#267 — the tier-axis explanation (docs) and origin of this proposal.
• datajoint-company/dj-brand#34 — canonical terminology decision.