generated/google/apis/spanner_v1/classes.rb in google-api-client-0.24.2 vs generated/google/apis/spanner_v1/classes.rb in google-api-client-0.24.3

- old
+ new

@@ -30,21 +30,27 @@ # Each session can have at most one active transaction at a time. After the # active transaction is completed, the session can immediately be # re-used for the next transaction. It is not necessary to create a # new session for each transaction. # # Transaction Modes - # Cloud Spanner supports two transaction modes: + # Cloud Spanner supports three transaction modes: # 1. Locking read-write. This type of transaction is the only way # to write data into Cloud Spanner. These transactions rely on # pessimistic locking and, if necessary, two-phase commit. # Locking read-write transactions may abort, requiring the # application to retry. # 2. Snapshot read-only. This transaction type provides guaranteed # consistency across several reads, but does not allow # writes. Snapshot read-only transactions can be configured to # read at timestamps in the past. Snapshot read-only # transactions do not need to be committed. + # 3. Partitioned DML. This type of transaction is used to execute + # a single Partitioned DML statement. Partitioned DML partitions + # the key space and runs the DML statement over each partition + # in parallel using separate, internal transactions that commit + # independently. Partitioned DML transactions do not need to be + # committed. # For transactions that only read, snapshot read-only transactions # provide simpler semantics and are almost always faster. In # particular, read-only transactions do not take locks, so they do # not conflict with read-write transactions. As a consequence of not # taking locks, they also do not abort, so retry loops are not needed. @@ -62,15 +68,12 @@ # transaction has not been terminated by # Commit or # Rollback. Long periods of # inactivity at the client may cause Cloud Spanner to release a # transaction's locks and abort it. - # Reads performed within a transaction acquire locks on the data - # being read. Writes can only be done at commit time, after all reads - # have been completed. # Conceptually, a read-write transaction consists of zero or more - # reads or SQL queries followed by + # reads or SQL statements followed by # Commit. At any time before # Commit, the client can send a # Rollback request to abort the # transaction. # ### Semantics @@ -192,11 +195,54 @@ # are one hour old. Because of this, Cloud Spanner cannot perform reads # at read timestamps more than one hour in the past. This # restriction also applies to in-progress reads and/or SQL queries whose # timestamp become too old while executing. Reads and SQL queries with # too-old read timestamps fail with the error `FAILED_PRECONDITION`. - # ## + # ## Partitioned DML Transactions + # Partitioned DML transactions are used to execute DML statements with a + # different execution strategy that provides different, and often better, + # scalability properties for large, table-wide operations than DML in a + # ReadWrite transaction. Smaller scoped statements, such as an OLTP workload, + # should prefer using ReadWrite transactions. + # Partitioned DML partitions the keyspace and runs the DML statement on each + # partition in separate, internal transactions. These transactions commit + # automatically when complete, and run independently from one another. + # To reduce lock contention, this execution strategy only acquires read locks + # on rows that match the WHERE clause of the statement. Additionally, the + # smaller per-partition transactions hold locks for less time. + # That said, Partitioned DML is not a drop-in replacement for standard DML used + # in ReadWrite transactions. + # - The DML statement must be fully-partitionable. Specifically, the statement + # must be expressible as the union of many statements which each access only + # a single row of the table. + # - The statement is not applied atomically to all rows of the table. Rather, + # the statement is applied atomically to partitions of the table, in + # independent transactions. Secondary index rows are updated atomically + # with the base table rows. + # - Partitioned DML does not guarantee exactly-once execution semantics + # against a partition. The statement will be applied at least once to each + # partition. It is strongly recommended that the DML statement should be + # idempotent to avoid unexpected results. For instance, it is potentially + # dangerous to run a statement such as + # `UPDATE table SET column = column + 1` as it could be run multiple times + # against some rows. + # - The partitions are committed automatically - there is no support for + # Commit or Rollback. If the call returns an error, or if the client issuing + # the ExecuteSql call dies, it is possible that some rows had the statement + # executed on them successfully. It is also possible that statement was + # never executed against other rows. + # - Partitioned DML transactions may only contain the execution of a single + # DML statement via ExecuteSql or ExecuteStreamingSql. + # - If any error is encountered during the execution of the partitioned DML + # operation (for instance, a UNIQUE INDEX violation, division by zero, or a + # value that cannot be stored due to schema constraints), then the + # operation is stopped at that point and an error is returned. It is + # possible that at this point, some partitions have been committed (or even + # committed multiple times), and other partitions have not been run at all. + # Given the above, Partitioned DML is good fit for large, database-wide, + # operations that are idempotent, such as deleting old rows from a very large + # table. # Corresponds to the JSON property `options` # @return [Google::Apis::SpannerV1::TransactionOptions] attr_accessor :options def initialize(**args) @@ -314,21 +360,27 @@ # Each session can have at most one active transaction at a time. After the # active transaction is completed, the session can immediately be # re-used for the next transaction. It is not necessary to create a # new session for each transaction. # # Transaction Modes - # Cloud Spanner supports two transaction modes: + # Cloud Spanner supports three transaction modes: # 1. Locking read-write. This type of transaction is the only way # to write data into Cloud Spanner. These transactions rely on # pessimistic locking and, if necessary, two-phase commit. # Locking read-write transactions may abort, requiring the # application to retry. # 2. Snapshot read-only. This transaction type provides guaranteed # consistency across several reads, but does not allow # writes. Snapshot read-only transactions can be configured to # read at timestamps in the past. Snapshot read-only # transactions do not need to be committed. + # 3. Partitioned DML. This type of transaction is used to execute + # a single Partitioned DML statement. Partitioned DML partitions + # the key space and runs the DML statement over each partition + # in parallel using separate, internal transactions that commit + # independently. Partitioned DML transactions do not need to be + # committed. # For transactions that only read, snapshot read-only transactions # provide simpler semantics and are almost always faster. In # particular, read-only transactions do not take locks, so they do # not conflict with read-write transactions. As a consequence of not # taking locks, they also do not abort, so retry loops are not needed. @@ -346,15 +398,12 @@ # transaction has not been terminated by # Commit or # Rollback. Long periods of # inactivity at the client may cause Cloud Spanner to release a # transaction's locks and abort it. - # Reads performed within a transaction acquire locks on the data - # being read. Writes can only be done at commit time, after all reads - # have been completed. # Conceptually, a read-write transaction consists of zero or more - # reads or SQL queries followed by + # reads or SQL statements followed by # Commit. At any time before # Commit, the client can send a # Rollback request to abort the # transaction. # ### Semantics @@ -476,11 +525,54 @@ # are one hour old. Because of this, Cloud Spanner cannot perform reads # at read timestamps more than one hour in the past. This # restriction also applies to in-progress reads and/or SQL queries whose # timestamp become too old while executing. Reads and SQL queries with # too-old read timestamps fail with the error `FAILED_PRECONDITION`. - # ## + # ## Partitioned DML Transactions + # Partitioned DML transactions are used to execute DML statements with a + # different execution strategy that provides different, and often better, + # scalability properties for large, table-wide operations than DML in a + # ReadWrite transaction. Smaller scoped statements, such as an OLTP workload, + # should prefer using ReadWrite transactions. + # Partitioned DML partitions the keyspace and runs the DML statement on each + # partition in separate, internal transactions. These transactions commit + # automatically when complete, and run independently from one another. + # To reduce lock contention, this execution strategy only acquires read locks + # on rows that match the WHERE clause of the statement. Additionally, the + # smaller per-partition transactions hold locks for less time. + # That said, Partitioned DML is not a drop-in replacement for standard DML used + # in ReadWrite transactions. + # - The DML statement must be fully-partitionable. Specifically, the statement + # must be expressible as the union of many statements which each access only + # a single row of the table. + # - The statement is not applied atomically to all rows of the table. Rather, + # the statement is applied atomically to partitions of the table, in + # independent transactions. Secondary index rows are updated atomically + # with the base table rows. + # - Partitioned DML does not guarantee exactly-once execution semantics + # against a partition. The statement will be applied at least once to each + # partition. It is strongly recommended that the DML statement should be + # idempotent to avoid unexpected results. For instance, it is potentially + # dangerous to run a statement such as + # `UPDATE table SET column = column + 1` as it could be run multiple times + # against some rows. + # - The partitions are committed automatically - there is no support for + # Commit or Rollback. If the call returns an error, or if the client issuing + # the ExecuteSql call dies, it is possible that some rows had the statement + # executed on them successfully. It is also possible that statement was + # never executed against other rows. + # - Partitioned DML transactions may only contain the execution of a single + # DML statement via ExecuteSql or ExecuteStreamingSql. + # - If any error is encountered during the execution of the partitioned DML + # operation (for instance, a UNIQUE INDEX violation, division by zero, or a + # value that cannot be stored due to schema constraints), then the + # operation is stopped at that point and an error is returned. It is + # possible that at this point, some partitions have been committed (or even + # committed multiple times), and other partitions have not been run at all. + # Given the above, Partitioned DML is good fit for large, database-wide, + # operations that are idempotent, such as deleting old rows from a very large + # table. # Corresponds to the JSON property `singleUseTransaction` # @return [Google::Apis::SpannerV1::TransactionOptions] attr_accessor :single_use_transaction # Commit a previously-started transaction. @@ -794,10 +886,22 @@ # Corresponds to the JSON property `resumeToken` # NOTE: Values are automatically base64 encoded/decoded in the client library. # @return [String] attr_accessor :resume_token + # A per-transaction sequence number used to identify this request. This + # makes each request idempotent such that if the request is received multiple + # times, at most one will succeed. + # 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 may be aborted. Replays of previously + # handled requests will yield the same response as the first execution. + # Required for DML statements. Ignored for queries. + # Corresponds to the JSON property `seqno` + # @return [Fixnum] + attr_accessor :seqno + # Required. The SQL string. # Corresponds to the JSON property `sql` # @return [String] attr_accessor :sql @@ -818,10 +922,11 @@ @param_types = args[:param_types] if args.key?(:param_types) @params = args[:params] if args.key?(:params) @partition_token = args[:partition_token] if args.key?(:partition_token) @query_mode = args[:query_mode] if args.key?(:query_mode) @resume_token = args[:resume_token] if args.key?(:resume_token) + @seqno = args[:seqno] if args.key?(:seqno) @sql = args[:sql] if args.key?(:sql) @transaction = args[:transaction] if args.key?(:transaction) end end @@ -1677,10 +1782,13 @@ # the query is not root partitionable. The query plan of a root # partitionable query has a single distributed union operator. A distributed # union operator conceptually divides one or more tables into multiple # splits, remotely evaluates a subquery independently on each split, and # then unions all results. + # This must not contain DML commands, such as INSERT, UPDATE, or + # DELETE. Use ExecuteStreamingSql with a + # PartitionedDml transaction for large, partition-friendly DML operations. # Corresponds to the JSON property `sql` # @return [String] attr_accessor :sql # This message is used to select the transaction in which a @@ -1790,10 +1898,23 @@ @partitions = args[:partitions] if args.key?(:partitions) @transaction = args[:transaction] if args.key?(:transaction) end end + # Message type to initiate a Partitioned DML transaction. + class PartitionedDml + include Google::Apis::Core::Hashable + + def initialize(**args) + update!(**args) + end + + # Update properties of this object + def update!(**args) + end + end + # Node information for nodes appearing in a QueryPlan.plan_nodes. class PlanNode include Google::Apis::Core::Hashable # List of child node `index`es and their relationship to this parent. @@ -2225,18 +2346,31 @@ # ` # Corresponds to the JSON property `queryStats` # @return [Hash<String,Object>] attr_accessor :query_stats + # Standard DML returns an exact count of rows that were modified. + # Corresponds to the JSON property `rowCountExact` + # @return [Fixnum] + attr_accessor :row_count_exact + + # Partitioned DML does not offer exactly-once semantics, so it + # returns a lower bound of the rows modified. + # Corresponds to the JSON property `rowCountLowerBound` + # @return [Fixnum] + attr_accessor :row_count_lower_bound + def initialize(**args) update!(**args) end # Update properties of this object def update!(**args) @query_plan = args[:query_plan] if args.key?(:query_plan) @query_stats = args[:query_stats] if args.key?(:query_stats) + @row_count_exact = args[:row_count_exact] if args.key?(:row_count_exact) + @row_count_lower_bound = args[:row_count_lower_bound] if args.key?(:row_count_lower_bound) end end # The request for Rollback. class RollbackRequest @@ -2565,21 +2699,27 @@ # Each session can have at most one active transaction at a time. After the # active transaction is completed, the session can immediately be # re-used for the next transaction. It is not necessary to create a # new session for each transaction. # # Transaction Modes - # Cloud Spanner supports two transaction modes: + # Cloud Spanner supports three transaction modes: # 1. Locking read-write. This type of transaction is the only way # to write data into Cloud Spanner. These transactions rely on # pessimistic locking and, if necessary, two-phase commit. # Locking read-write transactions may abort, requiring the # application to retry. # 2. Snapshot read-only. This transaction type provides guaranteed # consistency across several reads, but does not allow # writes. Snapshot read-only transactions can be configured to # read at timestamps in the past. Snapshot read-only # transactions do not need to be committed. + # 3. Partitioned DML. This type of transaction is used to execute + # a single Partitioned DML statement. Partitioned DML partitions + # the key space and runs the DML statement over each partition + # in parallel using separate, internal transactions that commit + # independently. Partitioned DML transactions do not need to be + # committed. # For transactions that only read, snapshot read-only transactions # provide simpler semantics and are almost always faster. In # particular, read-only transactions do not take locks, so they do # not conflict with read-write transactions. As a consequence of not # taking locks, they also do not abort, so retry loops are not needed. @@ -2597,15 +2737,12 @@ # transaction has not been terminated by # Commit or # Rollback. Long periods of # inactivity at the client may cause Cloud Spanner to release a # transaction's locks and abort it. - # Reads performed within a transaction acquire locks on the data - # being read. Writes can only be done at commit time, after all reads - # have been completed. # Conceptually, a read-write transaction consists of zero or more - # reads or SQL queries followed by + # reads or SQL statements followed by # Commit. At any time before # Commit, the client can send a # Rollback request to abort the # transaction. # ### Semantics @@ -2727,14 +2864,62 @@ # are one hour old. Because of this, Cloud Spanner cannot perform reads # at read timestamps more than one hour in the past. This # restriction also applies to in-progress reads and/or SQL queries whose # timestamp become too old while executing. Reads and SQL queries with # too-old read timestamps fail with the error `FAILED_PRECONDITION`. - # ## + # ## Partitioned DML Transactions + # Partitioned DML transactions are used to execute DML statements with a + # different execution strategy that provides different, and often better, + # scalability properties for large, table-wide operations than DML in a + # ReadWrite transaction. Smaller scoped statements, such as an OLTP workload, + # should prefer using ReadWrite transactions. + # Partitioned DML partitions the keyspace and runs the DML statement on each + # partition in separate, internal transactions. These transactions commit + # automatically when complete, and run independently from one another. + # To reduce lock contention, this execution strategy only acquires read locks + # on rows that match the WHERE clause of the statement. Additionally, the + # smaller per-partition transactions hold locks for less time. + # That said, Partitioned DML is not a drop-in replacement for standard DML used + # in ReadWrite transactions. + # - The DML statement must be fully-partitionable. Specifically, the statement + # must be expressible as the union of many statements which each access only + # a single row of the table. + # - The statement is not applied atomically to all rows of the table. Rather, + # the statement is applied atomically to partitions of the table, in + # independent transactions. Secondary index rows are updated atomically + # with the base table rows. + # - Partitioned DML does not guarantee exactly-once execution semantics + # against a partition. The statement will be applied at least once to each + # partition. It is strongly recommended that the DML statement should be + # idempotent to avoid unexpected results. For instance, it is potentially + # dangerous to run a statement such as + # `UPDATE table SET column = column + 1` as it could be run multiple times + # against some rows. + # - The partitions are committed automatically - there is no support for + # Commit or Rollback. If the call returns an error, or if the client issuing + # the ExecuteSql call dies, it is possible that some rows had the statement + # executed on them successfully. It is also possible that statement was + # never executed against other rows. + # - Partitioned DML transactions may only contain the execution of a single + # DML statement via ExecuteSql or ExecuteStreamingSql. + # - If any error is encountered during the execution of the partitioned DML + # operation (for instance, a UNIQUE INDEX violation, division by zero, or a + # value that cannot be stored due to schema constraints), then the + # operation is stopped at that point and an error is returned. It is + # possible that at this point, some partitions have been committed (or even + # committed multiple times), and other partitions have not been run at all. + # Given the above, Partitioned DML is good fit for large, database-wide, + # operations that are idempotent, such as deleting old rows from a very large + # table. class TransactionOptions include Google::Apis::Core::Hashable + # Message type to initiate a Partitioned DML transaction. + # Corresponds to the JSON property `partitionedDml` + # @return [Google::Apis::SpannerV1::PartitionedDml] + attr_accessor :partitioned_dml + # Message type to initiate a read-only transaction. # Corresponds to the JSON property `readOnly` # @return [Google::Apis::SpannerV1::ReadOnly] attr_accessor :read_only @@ -2748,10 +2933,11 @@ update!(**args) end # Update properties of this object def update!(**args) + @partitioned_dml = args[:partitioned_dml] if args.key?(:partitioned_dml) @read_only = args[:read_only] if args.key?(:read_only) @read_write = args[:read_write] if args.key?(:read_write) end end @@ -2766,21 +2952,27 @@ # Each session can have at most one active transaction at a time. After the # active transaction is completed, the session can immediately be # re-used for the next transaction. It is not necessary to create a # new session for each transaction. # # Transaction Modes - # Cloud Spanner supports two transaction modes: + # Cloud Spanner supports three transaction modes: # 1. Locking read-write. This type of transaction is the only way # to write data into Cloud Spanner. These transactions rely on # pessimistic locking and, if necessary, two-phase commit. # Locking read-write transactions may abort, requiring the # application to retry. # 2. Snapshot read-only. This transaction type provides guaranteed # consistency across several reads, but does not allow # writes. Snapshot read-only transactions can be configured to # read at timestamps in the past. Snapshot read-only # transactions do not need to be committed. + # 3. Partitioned DML. This type of transaction is used to execute + # a single Partitioned DML statement. Partitioned DML partitions + # the key space and runs the DML statement over each partition + # in parallel using separate, internal transactions that commit + # independently. Partitioned DML transactions do not need to be + # committed. # For transactions that only read, snapshot read-only transactions # provide simpler semantics and are almost always faster. In # particular, read-only transactions do not take locks, so they do # not conflict with read-write transactions. As a consequence of not # taking locks, they also do not abort, so retry loops are not needed. @@ -2798,15 +2990,12 @@ # transaction has not been terminated by # Commit or # Rollback. Long periods of # inactivity at the client may cause Cloud Spanner to release a # transaction's locks and abort it. - # Reads performed within a transaction acquire locks on the data - # being read. Writes can only be done at commit time, after all reads - # have been completed. # Conceptually, a read-write transaction consists of zero or more - # reads or SQL queries followed by + # reads or SQL statements followed by # Commit. At any time before # Commit, the client can send a # Rollback request to abort the # transaction. # ### Semantics @@ -2928,11 +3117,54 @@ # are one hour old. Because of this, Cloud Spanner cannot perform reads # at read timestamps more than one hour in the past. This # restriction also applies to in-progress reads and/or SQL queries whose # timestamp become too old while executing. Reads and SQL queries with # too-old read timestamps fail with the error `FAILED_PRECONDITION`. - # ## + # ## Partitioned DML Transactions + # Partitioned DML transactions are used to execute DML statements with a + # different execution strategy that provides different, and often better, + # scalability properties for large, table-wide operations than DML in a + # ReadWrite transaction. Smaller scoped statements, such as an OLTP workload, + # should prefer using ReadWrite transactions. + # Partitioned DML partitions the keyspace and runs the DML statement on each + # partition in separate, internal transactions. These transactions commit + # automatically when complete, and run independently from one another. + # To reduce lock contention, this execution strategy only acquires read locks + # on rows that match the WHERE clause of the statement. Additionally, the + # smaller per-partition transactions hold locks for less time. + # That said, Partitioned DML is not a drop-in replacement for standard DML used + # in ReadWrite transactions. + # - The DML statement must be fully-partitionable. Specifically, the statement + # must be expressible as the union of many statements which each access only + # a single row of the table. + # - The statement is not applied atomically to all rows of the table. Rather, + # the statement is applied atomically to partitions of the table, in + # independent transactions. Secondary index rows are updated atomically + # with the base table rows. + # - Partitioned DML does not guarantee exactly-once execution semantics + # against a partition. The statement will be applied at least once to each + # partition. It is strongly recommended that the DML statement should be + # idempotent to avoid unexpected results. For instance, it is potentially + # dangerous to run a statement such as + # `UPDATE table SET column = column + 1` as it could be run multiple times + # against some rows. + # - The partitions are committed automatically - there is no support for + # Commit or Rollback. If the call returns an error, or if the client issuing + # the ExecuteSql call dies, it is possible that some rows had the statement + # executed on them successfully. It is also possible that statement was + # never executed against other rows. + # - Partitioned DML transactions may only contain the execution of a single + # DML statement via ExecuteSql or ExecuteStreamingSql. + # - If any error is encountered during the execution of the partitioned DML + # operation (for instance, a UNIQUE INDEX violation, division by zero, or a + # value that cannot be stored due to schema constraints), then the + # operation is stopped at that point and an error is returned. It is + # possible that at this point, some partitions have been committed (or even + # committed multiple times), and other partitions have not been run at all. + # Given the above, Partitioned DML is good fit for large, database-wide, + # operations that are idempotent, such as deleting old rows from a very large + # table. # Corresponds to the JSON property `begin` # @return [Google::Apis::SpannerV1::TransactionOptions] attr_accessor :begin # Execute the read or SQL query in a previously-started transaction. @@ -2945,21 +3177,27 @@ # Each session can have at most one active transaction at a time. After the # active transaction is completed, the session can immediately be # re-used for the next transaction. It is not necessary to create a # new session for each transaction. # # Transaction Modes - # Cloud Spanner supports two transaction modes: + # Cloud Spanner supports three transaction modes: # 1. Locking read-write. This type of transaction is the only way # to write data into Cloud Spanner. These transactions rely on # pessimistic locking and, if necessary, two-phase commit. # Locking read-write transactions may abort, requiring the # application to retry. # 2. Snapshot read-only. This transaction type provides guaranteed # consistency across several reads, but does not allow # writes. Snapshot read-only transactions can be configured to # read at timestamps in the past. Snapshot read-only # transactions do not need to be committed. + # 3. Partitioned DML. This type of transaction is used to execute + # a single Partitioned DML statement. Partitioned DML partitions + # the key space and runs the DML statement over each partition + # in parallel using separate, internal transactions that commit + # independently. Partitioned DML transactions do not need to be + # committed. # For transactions that only read, snapshot read-only transactions # provide simpler semantics and are almost always faster. In # particular, read-only transactions do not take locks, so they do # not conflict with read-write transactions. As a consequence of not # taking locks, they also do not abort, so retry loops are not needed. @@ -2977,15 +3215,12 @@ # transaction has not been terminated by # Commit or # Rollback. Long periods of # inactivity at the client may cause Cloud Spanner to release a # transaction's locks and abort it. - # Reads performed within a transaction acquire locks on the data - # being read. Writes can only be done at commit time, after all reads - # have been completed. # Conceptually, a read-write transaction consists of zero or more - # reads or SQL queries followed by + # reads or SQL statements followed by # Commit. At any time before # Commit, the client can send a # Rollback request to abort the # transaction. # ### Semantics @@ -3107,10 +3342,53 @@ # are one hour old. Because of this, Cloud Spanner cannot perform reads # at read timestamps more than one hour in the past. This # restriction also applies to in-progress reads and/or SQL queries whose # timestamp become too old while executing. Reads and SQL queries with # too-old read timestamps fail with the error `FAILED_PRECONDITION`. - # ## + # ## Partitioned DML Transactions + # Partitioned DML transactions are used to execute DML statements with a + # different execution strategy that provides different, and often better, + # scalability properties for large, table-wide operations than DML in a + # ReadWrite transaction. Smaller scoped statements, such as an OLTP workload, + # should prefer using ReadWrite transactions. + # Partitioned DML partitions the keyspace and runs the DML statement on each + # partition in separate, internal transactions. These transactions commit + # automatically when complete, and run independently from one another. + # To reduce lock contention, this execution strategy only acquires read locks + # on rows that match the WHERE clause of the statement. Additionally, the + # smaller per-partition transactions hold locks for less time. + # That said, Partitioned DML is not a drop-in replacement for standard DML used + # in ReadWrite transactions. + # - The DML statement must be fully-partitionable. Specifically, the statement + # must be expressible as the union of many statements which each access only + # a single row of the table. + # - The statement is not applied atomically to all rows of the table. Rather, + # the statement is applied atomically to partitions of the table, in + # independent transactions. Secondary index rows are updated atomically + # with the base table rows. + # - Partitioned DML does not guarantee exactly-once execution semantics + # against a partition. The statement will be applied at least once to each + # partition. It is strongly recommended that the DML statement should be + # idempotent to avoid unexpected results. For instance, it is potentially + # dangerous to run a statement such as + # `UPDATE table SET column = column + 1` as it could be run multiple times + # against some rows. + # - The partitions are committed automatically - there is no support for + # Commit or Rollback. If the call returns an error, or if the client issuing + # the ExecuteSql call dies, it is possible that some rows had the statement + # executed on them successfully. It is also possible that statement was + # never executed against other rows. + # - Partitioned DML transactions may only contain the execution of a single + # DML statement via ExecuteSql or ExecuteStreamingSql. + # - If any error is encountered during the execution of the partitioned DML + # operation (for instance, a UNIQUE INDEX violation, division by zero, or a + # value that cannot be stored due to schema constraints), then the + # operation is stopped at that point and an error is returned. It is + # possible that at this point, some partitions have been committed (or even + # committed multiple times), and other partitions have not been run at all. + # Given the above, Partitioned DML is good fit for large, database-wide, + # operations that are idempotent, such as deleting old rows from a very large + # table. # Corresponds to the JSON property `singleUse` # @return [Google::Apis::SpannerV1::TransactionOptions] attr_accessor :single_use def initialize(**args)