attributes.account_id holding an account’s id, declared on a judgment so it reads the documents on the other end. Before your first judgment, you can ask which of your attributes already look like that.
Put related data in one namespace
Relations never cross namespaces. A namespace is a tenant or an environment, so if you want a judgment to read your CRM records and your support tickets together, write both into the same namespace:acme/prod/tenant_123, not acme/prod/tenant_123/crm and acme/prod/tenant_123/support. Decide this before your first write, since moving documents later means writing them again.
This is guidance for the relations you want, not a rule about every source. Data no judgment will ever read together can live in namespaces of its own.
Ask for suggestions
Once some documents are written, ask for suggestions. It creates nothing, and it is billed like a query, as the bytes of the documents it reads, within a fixed budget.Reading the response
Kinds. Your documents are split into kinds by one attribute with few distinct values, named inkind.attribute, with how many sampled documents hold each value. A status or a plan has as few values as a kind, so the other attributes that could have been the kind are listed in kind.candidates. If the wrong one was taken, pass another: ns.suggest_relations(kind="object") or ns.suggestRelations({ kind: "object" }). When no attribute qualifies, kind.attribute is null and the sample is one kind.
Relations. Each entry is one attribute on the sampled documents of one kind (from, up to 100 documents of it) whose values name live documents:
resolvedofsampled_values: how many of its present values name another document. The count is of values that are there, not of documents, so an attribute most documents leave out can still resolve 97 of 100.to: the kind most of those documents are, with every kind inresolved_by_kind.unresolvedand up to 5unresolved_examples: values that name no document, such as a deleted record, one not yet written, or a placeholder like"n/a".self_references: values naming the document that holds them. An account whoseaccount_idis its ownidresolves every time, but it points at itself, not at another record, so those values are counted here and never asresolved.array_lengths: for an attribute holding a list of ids, each element counts as one value, and the lists’ shortest, longest and mean lengths are shown beside them.
"open" can happen to be some document’s id. Check what an attribute means before you declare it. All counts are of the sample, not of the namespace: 97 of 100 sampled values means the attribute looks reliable, not that 97% of all values resolve.
Bounded and repeatable
The work has one budget: documents read, attributes examined, ids looked up and bytes read, each reported inbudget with its limit. When one runs out before every kind and attribute is examined, you get what was found so far, with complete: false and exhausted naming the dimension that ran out. Large attribute values, many kinds or long lists of ids are what use it up.
The call is billed like a query: usage.bytes_scanned is the bytes of the documents it read, the same as budget.bytes_read.used, so the budget also caps what one call costs.
The same namespace state gives the same sample, so asking again without writing gives the same answer. After writes, the sample can change.
On a template
On a template prefix, such asacme/prod/*, the sample is one tenant’s documents, named in tenant, as an example of what the template’s tenants hold. Ask on another tenant’s namespace to see its own.