--- title: "POST /v1/{+session}:executeBatchDml" method: POST path: "/v1/{+session}:executeBatchDml" tags: ["projects"] --- # POST /v1/{+session}:executeBatchDml `POST /v1/{+session}:executeBatchDml` Executes a batch of SQL DML statements. This method allows many statements to be run with lower latency than submitting them sequentially with ExecuteSql. Statements are executed in sequential order. A request can succeed even if a statement fails. The ExecuteBatchDmlResponse.status field in the response provides information about the statement that failed. Clients must inspect this field to determine whether an error occurred. Execution stops after the first failed statement; the remaining statements are not executed. ## Path parameters - `session` string, required ## Request body - ExecuteBatchDmlRequest — The request for ExecuteBatchDml. - `transaction` TransactionSelector — This message is used to select the transaction in which a Read or ExecuteSql call runs. See TransactionOptions for more information about transactions. - `singleUse` TransactionOptions — Options to use for transactions. - `readWrite` ReadWrite — Message type to initiate a read-write transaction. Currently this transaction type has no options. - `readLockMode` 'READ_LOCK_MODE_UNSPECIFIED' | 'PESSIMISTIC' | 'OPTIMISTIC' — The read lock mode for the transaction. - `multiplexedSessionPreviousTransactionId` string, byte — Optional. Clients should pass the transaction ID of the previous transaction attempt that was aborted if this transaction is being executed on a multiplexed session. - `partitionedDml` PartitionedDml — Message type to initiate a Partitioned DML transaction. - `readOnly` ReadOnly — Message type to initiate a read-only transaction. - `strong` boolean — Read at a timestamp where all previously committed transactions are visible. - `minReadTimestamp` string, google-datetime — Executes all reads at a timestamp >= `min_read_timestamp`. This is useful for requesting fresher data than some previous read, or data that is fresh enough to observe the effects of some previously committed transaction whose timestamp is known. Note that this option can only be used in single-use transactions. A timestamp in RFC3339 UTC \"Zulu\" format, accurate to nanoseconds. Example: `"2014-10-02T15:01:23.045123456Z"`. - `maxStaleness` string, google-duration — Read data at a timestamp >= `NOW - max_staleness` seconds. Guarantees that all writes that have committed more than the specified number of seconds ago are visible. Because Cloud Spanner chooses the exact timestamp, this mode works even if the client's local clock is substantially skewed from Cloud Spanner commit timestamps. Useful for reading the freshest data available at a nearby replica, while bounding the possible staleness if the local replica has fallen behind. Note that this option can only be used in single-use transactions. - `readTimestamp` string, google-datetime — Executes all reads at the given timestamp. Unlike other modes, reads at a specific timestamp are repeatable; the same read at the same timestamp always returns the same data. If the timestamp is in the future, the read is blocked until the specified timestamp, modulo the read's deadline. Useful for large scale consistent reads such as mapreduces, or for coordinating many reads against a consistent snapshot of the data. A timestamp in RFC3339 UTC \"Zulu\" format, accurate to nanoseconds. Example: `"2014-10-02T15:01:23.045123456Z"`. - `exactStaleness` string, google-duration — Executes all reads at a timestamp that is `exact_staleness` old. The timestamp is chosen soon after the read is started. Guarantees that all writes that have committed more than the specified number of seconds ago are visible. Because Cloud Spanner chooses the exact timestamp, this mode works even if the client's local clock is substantially skewed from Cloud Spanner commit timestamps. Useful for reading at nearby replicas without the distributed timestamp negotiation overhead of `max_staleness`. - `returnReadTimestamp` boolean — If true, the Cloud Spanner-selected read timestamp is included in the Transaction message that describes the transaction. - `excludeTxnFromChangeStreams` boolean — When `exclude_txn_from_change_streams` is set to `true`, it prevents read or write transactions from being tracked in change streams. * If the DDL option `allow_txn_exclusion` is set to `true`, then the updates made within this transaction aren't recorded in the change stream. * If you don't set the DDL option `allow_txn_exclusion` or if it's set to `false`, then the updates made within this transaction are recorded in the change stream. When `exclude_txn_from_change_streams` is set to `false` or not set, modifications from this transaction are recorded in all change streams that are tracking columns modified by these transactions. The `exclude_txn_from_change_streams` option can only be specified for read-write or partitioned DML transactions, otherwise the API returns an `INVALID_ARGUMENT` error. - `isolationLevel` 'ISOLATION_LEVEL_UNSPECIFIED' | 'SERIALIZABLE' | 'REPEATABLE_READ' — Isolation level for the transaction. - `id` string, byte — Execute the read or SQL query in a previously-started transaction. - `begin` TransactionOptions — Options to use for transactions. - `readWrite` ReadWrite — Message type to initiate a read-write transaction. Currently this transaction type has no options. - `readLockMode` 'READ_LOCK_MODE_UNSPECIFIED' | 'PESSIMISTIC' | 'OPTIMISTIC' — The read lock mode for the transaction. - `multiplexedSessionPreviousTransactionId` string, byte — Optional. Clients should pass the transaction ID of the previous transaction attempt that was aborted if this transaction is being executed on a multiplexed session. - `partitionedDml` PartitionedDml — Message type to initiate a Partitioned DML transaction. - `readOnly` ReadOnly — Message type to initiate a read-only transaction. - `strong` boolean — Read at a timestamp where all previously committed transactions are visible. - `minReadTimestamp` string, google-datetime — Executes all reads at a timestamp >= `min_read_timestamp`. This is useful for requesting fresher data than some previous read, or data that is fresh enough to observe the effects of some previously committed transaction whose timestamp is known. Note that this option can only be used in single-use transactions. A timestamp in RFC3339 UTC \"Zulu\" format, accurate to nanoseconds. Example: `"2014-10-02T15:01:23.045123456Z"`. - `maxStaleness` string, google-duration — Read data at a timestamp >= `NOW - max_staleness` seconds. Guarantees that all writes that have committed more than the specified number of seconds ago are visible. Because Cloud Spanner chooses the exact timestamp, this mode works even if the client's local clock is substantially skewed from Cloud Spanner commit timestamps. Useful for reading the freshest data available at a nearby replica, while bounding the possible staleness if the local replica has fallen behind. Note that this option can only be used in single-use transactions. - `readTimestamp` string, google-datetime — Executes all reads at the given timestamp. Unlike other modes, reads at a specific timestamp are repeatable; the same read at the same timestamp always returns the same data. If the timestamp is in the future, the read is blocked until the specified timestamp, modulo the read's deadline. Useful for large scale consistent reads such as mapreduces, or for coordinating many reads against a consistent snapshot of the data. A timestamp in RFC3339 UTC \"Zulu\" format, accurate to nanoseconds. Example: `"2014-10-02T15:01:23.045123456Z"`. - `exactStaleness` string, google-duration — Executes all reads at a timestamp that is `exact_staleness` old. The timestamp is chosen soon after the read is started. Guarantees that all writes that have committed more than the specified number of seconds ago are visible. Because Cloud Spanner chooses the exact timestamp, this mode works even if the client's local clock is substantially skewed from Cloud Spanner commit timestamps. Useful for reading at nearby replicas without the distributed timestamp negotiation overhead of `max_staleness`. - `returnReadTimestamp` boolean — If true, the Cloud Spanner-selected read timestamp is included in the Transaction message that describes the transaction. - `excludeTxnFromChangeStreams` boolean — When `exclude_txn_from_change_streams` is set to `true`, it prevents read or write transactions from being tracked in change streams. * If the DDL option `allow_txn_exclusion` is set to `true`, then the updates made within this transaction aren't recorded in the change stream. * If you don't set the DDL option `allow_txn_exclusion` or if it's set to `false`, then the updates made within this transaction are recorded in the change stream. When `exclude_txn_from_change_streams` is set to `false` or not set, modifications from this transaction are recorded in all change streams that are tracking columns modified by these transactions. The `exclude_txn_from_change_streams` option can only be specified for read-write or partitioned DML transactions, otherwise the API returns an `INVALID_ARGUMENT` error. - `isolationLevel` 'ISOLATION_LEVEL_UNSPECIFIED' | 'SERIALIZABLE' | 'REPEATABLE_READ' — Isolation level for the transaction. - `statements` Statement[] — Required. The list of statements to execute in this batch. Statements are executed serially, such that the effects of statement `i` are visible to statement `i+1`. Each statement must be a DML statement. Execution stops at the first failed statement; the remaining statements are not executed. Callers must provide at least one statement. - `sql` string — Required. The DML string. - `params` object — Parameter names and values that bind to placeholders in the DML string. A parameter placeholder consists of the `@` character followed by the parameter name (for example, `@firstName`). Parameter names can contain letters, numbers, and underscores. Parameters can appear anywhere that a literal value is expected. The same parameter name can be used more than once, for example: `"WHERE id > @msg_id AND id < @msg_id + 100"` It's an error to execute a SQL statement with unbound parameters. - `paramTypes` object — It isn't always possible for Cloud Spanner to infer the right SQL type from a JSON value. For example, values of type `BYTES` and values of type `STRING` both appear in params as JSON strings. In these cases, `param_types` can be used to specify the exact SQL type for some or all of the SQL statement parameters. See the definition of Type for more information about SQL types. - `seqno` string, int64 — Required. A per-transaction sequence number used to identify this request. This field makes each request idempotent such that if the request is received multiple times, at most one succeeds. The sequence number must be monotonically increasing within the transaction. If a request arrives for the first time with an out-of-order sequence number, the transaction might be aborted. Replays of previously handled requests yield the same response as the first execution. - `requestOptions` RequestOptions — Common request options for various APIs. - `priority` 'PRIORITY_UNSPECIFIED' | 'PRIORITY_LOW' | 'PRIORITY_MEDIUM' | 'PRIORITY_HIGH' — Priority for the request. - `requestTag` string — A per-request tag which can be applied to queries or reads, used for statistics collection. Both `request_tag` and `transaction_tag` can be specified for a read or query that belongs to a transaction. This field is ignored for requests where it's not applicable (for example, `CommitRequest`). Legal characters for `request_tag` values are all printable characters (ASCII 32 - 126) and the length of a request_tag is limited to 50 characters. Values that exceed this limit are truncated. Any leading underscore (_) characters are removed from the string. - `transactionTag` string — A tag used for statistics collection about this transaction. Both `request_tag` and `transaction_tag` can be specified for a read or query that belongs to a transaction. To enable tagging on a transaction, `transaction_tag` must be set to the same value for all requests belonging to the same transaction, including BeginTransaction. If this request doesn't belong to any transaction, `transaction_tag` is ignored. Legal characters for `transaction_tag` values are all printable characters (ASCII 32 - 126) and the length of a `transaction_tag` is limited to 50 characters. Values that exceed this limit are truncated. Any leading underscore (_) characters are removed from the string. - `clientContext` ClientContext — Container for various pieces of client-owned context attached to a request. - `secureContext` object — Optional. Map of parameter name to value for this request. These values will be returned by any SECURE_CONTEXT() calls invoked by this request (e.g., by queries against Parameterized Secure Views). - `lastStatements` boolean — Optional. If set to `true`, this request marks the end of the transaction. After these statements execute, you must commit or abort the transaction. Attempts to execute any other requests against this transaction (including reads and queries) are rejected. Setting this option might cause some error reporting to be deferred until commit time (for example, validation of unique constraints). Given this, successful execution of statements shouldn't be assumed until a subsequent `Commit` call completes successfully. ## Response `200` Successful response --- [API](https://skmtc.net/google/apis/spanner.md) · [All operations](https://skmtc.net/google/apis/spanner/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/google/spanner/versions/4b66067d2622/schema)