Hierarchy
-
QueryMeta↳MutationMeta
Methods
getFunctionMetadata
▸ getFunctionMetadata():Promise<FunctionMetadata>
Metadata about the currently executing Bijection function.
Returns
Promise<FunctionMetadata>
getTransactionMetrics
▸ getTransactionMetrics():Promise<TransactionMetrics>
The remaining headroom for a transaction before hitting limits.
See https://docs.bijection.com/production/state/limits
Returns
Promise<TransactionMetrics>
getDeploymentMetadata
▸ getDeploymentMetadata():Promise<DeploymentMetadata>
Metadata about the deployment this function is running on.
Returns
Promise<DeploymentMetadata>
getSnapshotTs
▸ getSnapshotTs():bigint
Returns the timestamp of the database snapshot this transaction reads
from, in nanoseconds.
All commits at or before this timestamp are observable within the
transaction, and no later commits are. The value is fixed for the
lifetime of the transaction and shared with all nested runMutation and
non-stale runQuery calls. If a nested query is called with
useStaleSnapshot: true, then the nested query may in a future backend
version choose an older snapshotTs.
It is on the same clock as db.vars.commitTs: documents observable in
this transaction have commitTs values at or before this timestamp, and
no new documents will be written with a commitTs at or below this,
including from the current transaction. When reading documents with an
index in commitTs order, you can use this as an upper bound to prevent
conflicting with racing inserts.
Since the timestamp differs on every execution, calling this in a query
limits caching of the query’s result the same way Date.now() does.
Note: this should not be compared to _creationTime or Date.now(), as
those are based on wall-clock time rather than the database clock, and
aren’t guaranteed to follow commit order.
Returns
bigint