dj.Entry, dj.Ingest and dj.Compute as tier names on one axis

[dimitri-yatsenko]

The 2.3.4 half of #1546: the new names become available, and nothing else changes.

Why

The populated tiers sit on inconsistent axes. Manual names the writer but means the origin; Imported names the origin but means the writer; Computed names the result. A reader reasoning from the names alone lands in the wrong tier, and the failure has a recognizable shape: an Imported table with no make(), populate() silently doing nothing, and a permanent allow_direct_insert=True suppressing a guard that was reporting a real modeling error.

The new names put all four on one question — what puts rows in this table? — and the grammar carries it: the nouns are tables something else fills, the verbs are precisely the two things populate() does.

Tier		What puts rows in it
Lookup	noun	the code, via contents
Entry	noun	a writer outside the table — a person, an instrument, an entry script
Ingest	verb	the table's own make(), reading an external source
Compute	verb	the table's own make(), deriving from other DataJoint tables

Aliases, not subclasses

Entry = Manual
Ingest = Imported
Compute = Computed

Three assignments. A table declared either way is the same class — same SQL prefix, same Role, same tier detection, same CREATE TABLE. That is not an invariant someone has to maintain; it is one that cannot be broken, which is why this is three lines rather than a parallel hierarchy.

Lookup and Part are unchanged: Lookup already sits on the axis, and Part is a structural role rather than a fourth answer to the same question.

What does not change in 2.3.4

Defaults, repr, introspection, dj.Diagram tier labels, and what the documentation teaches all stay on the old names. Early adopters and new examples can use the new ones immediately with zero migration; the terminology sweep is 2.4.

Manual, Imported and Computed are permanent aliases — no deprecation at any point, no migration, no broken tutorials, no broken third-party code. The names have been in constant use for a decade and they keep working indefinitely.

Verification

• Full integration suite: 673 passed, 14 skipped, 0 failed across MySQL and PostgreSQL.
• 16 new unit tests covering the transparency checks Rename the table tiers to a consistent axis — dj.Entry, dj.Ingest, dj.Compute (keep Manual/Imported/Computed as permanent aliases) #1546 asks for: identity rather than subclassing, SQL prefix against Role, package exports, tier detection by prefix for all five tiers, and that Lookup/Part are untouched.
• Checked end to end that class ViaOld(dj.Manual) and class ViaNew(dj.Entry) with the same definition emit byte-identical CREATE TABLE.
• ruff, ruff-format, codespell, mypy pass via pre-commit.

Note on naming, from the #1546 discussion

Compute rather than Derive: in relational databases a derived table is the result of a query — computed on read, not stored — which is the opposite of this tier, whose rows are materialized by make() and persisted with lineage. Derive would collide head-on with that meaning for exactly our most database-literate readers.

The verb-as-class-name cost raised by @gtouloumes is real and accepted: class TuningCurve(dj.Compute) takes getting used to. It is an adoption cost, not a correctness objection, and the docs reinforce the axis where the names are introduced.

[lum-agilyti]

Approving. The aliases are the same objects as the old classes, so prefix, Role and tier detection can't diverge. A few notes on the tests:

1. test_lookup_and_part_are_unchanged: assert not hasattr(dj, "LookupAlias") always passes, since nothing is or would be named that.
2. test_declaring_either_way_produces_the_same_table_name doesn't compare the two tables. from_camel_case("Subject") doesn't involve ViaOld/ViaNew, and the _prefix and type(...) checks already follow from test_alias_is_the_same_class. Nothing checks that both spellings produce the same CREATE TABLE.
3. The module docstring lists lookup_class_name among the checks, but no test calls it.