Class: Google::Apis::SpannerV1::CommitRequest

Inherits:
Object
  • Object
show all
Includes:
Core::Hashable, Core::JsonObjectSupport
Defined in:
lib/google/apis/spanner_v1/classes.rb,
lib/google/apis/spanner_v1/representations.rb,
lib/google/apis/spanner_v1/representations.rb

Overview

The request for Commit.

Instance Attribute Summary collapse

Instance Method Summary collapse

Constructor Details

#initialize(**args) ⇒ CommitRequest

Returns a new instance of CommitRequest.



479
480
481
 
# File 'lib/google/apis/spanner_v1/classes.rb', line 479

def initialize(**args)
   update!(**args)
end

Instance Attribute Details

#mutations ⇒ Array<Google::Apis::SpannerV1::Mutation>

The mutations to be executed when this transaction commits. All mutations are applied atomically, in the order they appear in this list. Corresponds to the JSON property mutations

Returns:



412
413
414
 
# File 'lib/google/apis/spanner_v1/classes.rb', line 412

def mutations
  @mutations
end

#request_options ⇒ Google::Apis::SpannerV1::RequestOptions

Common request options for various APIs. Corresponds to the JSON property requestOptions

Returns:



417
418
419
 
# File 'lib/google/apis/spanner_v1/classes.rb', line 417

def request_options
  @request_options
end

#return_commit_stats ⇒ Boolean Also known as: return_commit_stats?

If true, then statistics related to the transaction will be included in the CommitResponse. Default value is false. Corresponds to the JSON property returnCommitStats

Returns:

  • (Boolean) 


423
424
425
 
# File 'lib/google/apis/spanner_v1/classes.rb', line 423

def return_commit_stats
  @return_commit_stats
end

#single_use_transaction ⇒ Google::Apis::SpannerV1::TransactionOptions

In addition, if TransactionOptions.read_only.return_read_timestamp is set to true, a special value of 2^63 - 2 will be returned in the Transaction message that describes the transaction, instead of a valid read timestamp. This special value should be discarded and not used for any subsequent queries. Please see https://cloud.google.com/spanner/docs/change-streams for more details on how to query the change stream TVFs. 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

Returns:



471
472
473
 
# File 'lib/google/apis/spanner_v1/classes.rb', line 471

def single_use_transaction
  @single_use_transaction
end

#transaction_id ⇒ String

Commit a previously-started transaction. Corresponds to the JSON property transactionId NOTE: Values are automatically base64 encoded/decoded in the client library.

Returns:

  • (String) 


477
478
479
 
# File 'lib/google/apis/spanner_v1/classes.rb', line 477

def transaction_id
  @transaction_id
end

Instance Method Details

#update!(**args) ⇒ Object

Update properties of this object



484
485
486
487
488
489
490
 
# File 'lib/google/apis/spanner_v1/classes.rb', line 484

def update!(**args)
  @mutations = args[:mutations] if args.key?(:mutations)
  @request_options = args[:request_options] if args.key?(:request_options)
  @return_commit_stats = args[:return_commit_stats] if args.key?(:return_commit_stats)
  @single_use_transaction = args[:single_use_transaction] if args.key?(:single_use_transaction)
  @transaction_id = args[:transaction_id] if args.key?(:transaction_id)
end