Discover keys
The semantic catalog exposes the same model as
primaryKey and
importedForeignKeys on each table.
Preserve table grain
A main Provider table and its child tables have different keys. For example, an issue can have many labels, so the parent issue ID repeats inproviders.github.issues__labels. Use the complete logical key returned by the
catalog instead of deduplicating a child table on its parent ID.
Provider Plugins define the business key and ordering behavior used to project
source records. Consumers inspect that metadata; they do not redefine it in a
query.
Join a child table to its parent
The catalog relates each child table to its parent: the child’sparent_pk
column references the parent’s key. parent_pk is text, so plain equality
with the parent’s key works only for a string key. Compare parent_pk with
the parent key in the text form Parable stores, as the _with_parent and
_nested convenience views do:
number) key of magnitude 1e16 or more does not round-trip.
parent_pk holds it with a plus sign in the exponent (1e+16), and
CAST(key AS VARCHAR) prints 1e16, so the children of that parent do not
join, by hand or through the views. Smaller floating-point keys and integer
keys round-trip.
Prefer semantic joins
Use a relationship from the catalog when one exists; a child table’s relationship to its parent compares keys as above. Otherwise, choose columns that represent the same semantic value or domain key:- Join
Contact.Emailvalues across Provider and Workspace tables. - Join Provider-native IDs only inside the Provider domain that owns them.
- Use
providers.identity.account_associationswhen accounts for the same person do not share an email. Itsemailcolumn isContact.Email, so a Provider or Workspace email joins to it directly. - Join work items on a real shared domain key, such as a branch name, rather than similarly named IDs.