Expand description
lint — the two questions worth asking about a shape, before and
after the table exists.
Lessons 1 and 6 of the migration playbook. They are one deliverable in the plan and two commands here, because they run at different moments and answer differently.
lint overlap is lesson 1, and it is not the check the plan
first described. That plan said to sample a candidate column and see
whether it is single-valued — but a hash field holds one value by
construction, so that check passes forever. The lesson says where
the answer really lives: “the answer is usually in your
id-derivation or key-construction code, not in the row itself — a
thread can live in several mailboxes.” The symptom of that is
in the data, just not in the row: the same name appears under more
than one owner. So this reads the family of owner-keyed collections
and asks whether they intersect. They do ⇒ no column can carry that
dimension, and a membership row is the shape.
lint columns is lesson 6, and it can only run after the
table is declared — it reads rows. Two columns whose values coincide
on nearly every row are one column copied to get a second sort
order; the answer is another ORDERPATH, which IDX.ADVISE names.
The exit codes differ on purpose. Overlap is an answer: a column cannot carry a multi-valued dimension, so a script should stop. Coincidence is a suspicion — two columns may legitimately agree — so it reports and exits zero.
Structs§
- Coincidence
- Two columns that agree on most of the rows they both appear in.
- Overlap
- What the owner-keyed collections under a prefix look like together.
Functions§
- column_
pairs - Sample rows under a prefix and find column pairs that nearly always carry the same value.
- overlap
- Read every collection under
prefixand see whether they intersect. - run_
lint_ cli lint overlap --prefix <p>/lint columns <table> [--sample N] [--threshold PCT]