google-api-client 0.24.2 → 0.24.3

data/generated/google/apis/serviceuser_v1/representations.rb

@@ -214,18 +214,6 @@ module Google
         include Google::Apis::Core::JsonObjectSupport
       end
       
-      class MediaDownload
-        class Representation < Google::Apis::Core::JsonRepresentation; end
-      
-        include Google::Apis::Core::JsonObjectSupport
-      end
-      
-      class MediaUpload
-        class Representation < Google::Apis::Core::JsonRepresentation; end
-      
-        include Google::Apis::Core::JsonObjectSupport
-      end
-      
       class MethodProp
         class Representation < Google::Apis::Core::JsonRepresentation; end
       
@@ -657,10 +645,6 @@ module Google
       
           property :delete, as: 'delete'
           property :get, as: 'get'
-          property :media_download, as: 'mediaDownload', class: Google::Apis::ServiceuserV1::MediaDownload, decorator: Google::Apis::ServiceuserV1::MediaDownload::Representation
-      
-          property :media_upload, as: 'mediaUpload', class: Google::Apis::ServiceuserV1::MediaUpload, decorator: Google::Apis::ServiceuserV1::MediaUpload::Representation
-      
           property :patch, as: 'patch'
           property :post, as: 'post'
           property :put, as: 'put'
@@ -716,32 +700,6 @@ module Google
         end
       end
       
-      class MediaDownload
-        # @private
-        class Representation < Google::Apis::Core::JsonRepresentation
-          property :complete_notification, as: 'completeNotification'
-          property :download_service, as: 'downloadService'
-          property :dropzone, as: 'dropzone'
-          property :enabled, as: 'enabled'
-          property :max_direct_download_size, :numeric_string => true, as: 'maxDirectDownloadSize'
-          property :use_direct_download, as: 'useDirectDownload'
-        end
-      end
-      
-      class MediaUpload
-        # @private
-        class Representation < Google::Apis::Core::JsonRepresentation
-          property :complete_notification, as: 'completeNotification'
-          property :dropzone, as: 'dropzone'
-          property :enabled, as: 'enabled'
-          property :max_size, :numeric_string => true, as: 'maxSize'
-          collection :mime_types, as: 'mimeTypes'
-          property :progress_notification, as: 'progressNotification'
-          property :start_notification, as: 'startNotification'
-          property :upload_service, as: 'uploadService'
-        end
-      end
-      
       class MethodProp
         # @private
         class Representation < Google::Apis::Core::JsonRepresentation

data/generated/google/apis/spanner_v1.rb

@@ -26,7 +26,7 @@ module Google
     # @see https://cloud.google.com/spanner/
     module SpannerV1
       VERSION = 'V1'
-      REVISION = '20180906'
+      REVISION = '20180920'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

data/generated/google/apis/spanner_v1/classes.rb

@@ -32,7 +32,7 @@ module Google
         # 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.
@@ -43,6 +43,12 @@ module Google
         # 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
@@ -64,11 +70,8 @@ module Google
         # 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
@@ -194,7 +197,50 @@ module Google
         # 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
@@ -316,7 +362,7 @@ module Google
         # 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.
@@ -327,6 +373,12 @@ module Google
         # 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
@@ -348,11 +400,8 @@ module Google
         # 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
@@ -478,7 +527,50 @@ module Google
         # 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
@@ -796,6 +888,18 @@ module Google
         # @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]
@@ -820,6 +924,7 @@ module Google
           @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
@@ -1679,6 +1784,9 @@ module Google
         # 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
@@ -1792,6 +1900,19 @@ module Google
         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
@@ -2227,6 +2348,17 @@ module Google
         # @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
@@ -2235,6 +2367,8 @@ module Google
         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
       
@@ -2567,7 +2701,7 @@ module Google
       # 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.
@@ -2578,6 +2712,12 @@ module Google
       # 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
@@ -2599,11 +2739,8 @@ module Google
       # 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
@@ -2729,10 +2866,58 @@ module Google
       # 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]
@@ -2750,6 +2935,7 @@ module Google
       
         # 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
@@ -2768,7 +2954,7 @@ module Google
         # 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.
@@ -2779,6 +2965,12 @@ module Google
         # 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
@@ -2800,11 +2992,8 @@ module Google
         # 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
@@ -2930,7 +3119,50 @@ module Google
         # 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
@@ -2947,7 +3179,7 @@ module Google
         # 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.
@@ -2958,6 +3190,12 @@ module Google
         # 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
@@ -2979,11 +3217,8 @@ module Google
         # 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
@@ -3109,7 +3344,50 @@ module Google
         # 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