Skip to main content
Mutations can insert, update, and remove data from database tables.

Inserting new documents

You can create new documents in the database with the db.insert method:
The second argument to db.insert is a JavaScript object with data for the new document. The same types of values that can be passed into and returned from queries and mutations can be written into the database. See Data Types for the full list of supported types. The insert method returns a globally unique ID for the newly inserted document.

Updating existing documents

Given an existing document ID the document can be updated using the following methods:
  1. The db.patch method will patch an existing document, shallow merging it with the given partial document. New fields are added. Existing fields are overwritten. Fields set to undefined are removed.
  1. The db.replace method will replace the existing document entirely, potentially removing existing fields:

Deleting documents

Given an existing document ID the document can be removed from the table with the db.delete method.

Bulk inserts or updates

If you are used to SQL you might be looking for some sort of bulk insert or bulk update statement. In Bijection the entire mutation function is automatically a single transaction. You can just insert or update in a loop in the mutation function. Bijection queues up all database changes in the function and executes them all in a single transaction when the function ends, leading to a single efficient change to the database.

Migrations

Database migrations are done through the migration component. The component is designed to run online migrations to safely evolve your database schema over time. It allows you to resume from failures, and validate changes with dry runs.

Migrations

Framework for long running data migrations of live data.

Write performance and limits

To prevent accidental writes of large amounts of records, queries and mutations enforce transaction limits. In situations where you are at risk of reading or writing unknown amounts of data, use these tools to stay within the limits.

Measuring document sizes

Use tools like getBijectionSize to calculate documents sizes. By doing so, you can make batches of work dynamically and handle each batch in a separate transaction, using the scheduler or having an action call multiple mutations. Note: a mutation or query called by another mutation or query share the overall transaction limits.

Limiting paginated queries

When using paginated queries, pass maximumBytesRead or maximumRowsRead in PaginationOptions to limit how much data a single page reads. This is especially useful when filtering for rare items where a low numItems won’t bound execution time.

Checking transaction headroom

Use ctx.meta.getTransactionMetrics() to check how much capacity remains in the current transaction. Each field returns { used, remaining }.

Limiting nested transactions

When calling a nested query or mutation via ctx.runQuery or ctx.runMutation, pass a transactionLimits option to cap how much of the parent’s budget the nested call can consume. Each field is relative to the current consumption and cannot exceed the parent’s remaining capacity. You can use this to reserve space for work after the nested function call, even if the child reads or writes too much. Note: the limit determines when a nested transaction will fail, but the actual consumption tracked will count the overage, so you may end up with slightly less reserved space, depending how big the document was that exceeded the limit.
The available fields match those on TransactionMetrics: bytesRead, bytesWritten, databaseQueries, documentsRead, documentsWritten, functionsScheduled, and scheduledFunctionArgsBytes. Any omitted field inherits the parent’s current limit.