Workspace database writes that land together or not at all

Saving one thing to a workspace database often takes more than one row: a new lead and the row that says who owns it, an order and its line items. Until now each of those rows went in its own request, so a database hiccup between two of them could save the lead and drop its owner. Specialists, apps, and workflows can now send related rows as one request that the database applies completely or not at all.

How it works

• One request, every value bound. A request can carry a list of statements, each with its own ? placeholders and values, and the database runs them as one transaction. Before, statements could only be grouped when they carried no values, so most real writes went one at a time.
• All or nothing. If any statement fails, none of them are kept, and the database is left as it was before the request.
• One answer per statement. The reply lists each statement's rows and row count in order, so a write and the read that checks it can share one request.
• Safe after an outage. An error can arrive after a write already landed, so specialists are now told to read back what is there before writing again, instead of guessing.

Also shipped

• Batched reads retry too. A request made only of reads is retried through a short outage, as a single read already was.