Entity detection & schema
Tablyne detects the entity types in an overloaded table and infers a schema for each.
The Entities tab reads your loaded items, groups them by inferred entity type, and shows a per-entity schema, a clean data table, and the access patterns each entity supports.
How entities are detected
In a single-table design the keys are overloaded with TYPE#id prefixes. Tablyne uses that convention to label each item:
- The sort-key prefix before the first
#wins (ORDER#9001→ORDER,PROFILE→PROFILE). - If the sort key has no usable prefix, the partition-key prefix is used (
USER#42→USER). - If neither key carries a prefix, an explicit discriminator attribute is checked:
__typename,_typename,entityType,entity_type,_type,_et,recordType,record_type. - Items with no detectable type are treated as one entity — the table itself — so a plain relational-style table isn’t shredded.
A safety net guards against false positives: if the detected “types” are almost as numerous as the items (an id-keyed table whose prefixes are all unique), Tablyne collapses everything into a single entity rather than inventing one entity per row. A table counts as a real single-table design only when two or more genuine entity types are found.
The entity rail
The left rail lists every detected entity, sorted by item count, each with an accent color, its sampled count, and its key patterns:
● Order 1,204 PK=USER#<id> · SK=ORDER#<id>
● User 312 PK=USER#<id> · SK=PROFILE
● Payment 980 PK=USER#<id> · SK=PAY#<id>Select one to inspect it. Counts are sample counts until you run count all from the scan bar — see /docs/std-overview/ for sample-vs-full-scan behaviour.
The inferred schema
For the selected entity, Tablyne unions every attribute seen across that entity’s items and infers, per attribute:
| Column | Meaning |
|---|---|
| Name | The attribute key |
| Types | Observed DynamoDB types — S, N, BOOL, L, M, NULL (multiple if the data is mixed) |
| Key role | PK, SK, or GSI1 PK / GSI1 SK when the attribute is a key |
| Required | ● if present on every sampled item of the entity, ○ otherwise |
| Example | A real value pulled from the data |
Key attributes are listed first, then alphabetically. Key roles are color-coded (PK cyan, SK magenta, GSI violet). Because the schema is unioned over a sample, an attribute that only appears on items you haven’t loaded won’t show until you count all.
Clean data table
Below the schema, the entity’s items are shown as a friendly table: an id column (the segment after the TYPE# prefix) plus only that entity’s non-key attributes — no noisy overloaded keys. The table shows up to 50 rows; the header reads sample on a partial load and whole table after a full scan.
Access patterns
Each entity lists the reads it supports, derived from its keys and relationships:
- Get —
Query PK=… SK=…for a specific item. - By parent —
Query PK=… SK begins_with TYPE#to fetch a child item-collection. - By GSI —
Query GSI… PK=…for each index the entity participates in. - By a non-key attribute — flagged as a
Scan + filter, marked unsupported, because DynamoDB can’t serve it efficiently.
Query patterns are green; the Scan pattern is red and carries a suggest GSI button. Clicking it explains the global secondary index that would turn that Scan into a Query and opens the migration wizard. The full diagnosis is covered in /docs/access-patterns/.
Entity lens in the Data view
You don’t have to leave the grid to think in entities. The ◧ toggle in the Data tab toolbar switches on the entity lens: the same rows, grouped under collapsible color-coded entity headers, each group showing only that entity’s relevant columns. It’s the familiar grid, made entity-aware.
Limitations
- Convention-dependent: detection relies on
TYPE#prefixes or a known discriminator attribute. Non-standard designs may read as a single entity. - Sample-bound: schema, types, coverage and counts reflect loaded rows until you count all.
- The generic
typeattribute is ignored as a discriminator on purpose — it usually denotes a data type and would wrongly shred a config table.