google-cloud-spanner-v1 0.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (37) hide show
  1. checksums.yaml +7 -0
  2. data/.yardopts +12 -0
  3. data/AUTHENTICATION.md +169 -0
  4. data/LICENSE.md +203 -0
  5. data/README.md +75 -0
  6. data/lib/google-cloud-spanner-v1.rb +21 -0
  7. data/lib/google/cloud/spanner/v1.rb +35 -0
  8. data/lib/google/cloud/spanner/v1/spanner.rb +52 -0
  9. data/lib/google/cloud/spanner/v1/spanner/client.rb +1947 -0
  10. data/lib/google/cloud/spanner/v1/spanner/credentials.rb +52 -0
  11. data/lib/google/cloud/spanner/v1/spanner/paths.rb +73 -0
  12. data/lib/google/cloud/spanner/v1/version.rb +28 -0
  13. data/lib/google/spanner/v1/keys_pb.rb +37 -0
  14. data/lib/google/spanner/v1/mutation_pb.rb +42 -0
  15. data/lib/google/spanner/v1/query_plan_pb.rb +51 -0
  16. data/lib/google/spanner/v1/result_set_pb.rb +51 -0
  17. data/lib/google/spanner/v1/spanner_pb.rb +182 -0
  18. data/lib/google/spanner/v1/spanner_services_pb.rb +180 -0
  19. data/lib/google/spanner/v1/transaction_pb.rb +59 -0
  20. data/lib/google/spanner/v1/type_pb.rb +47 -0
  21. data/proto_docs/README.md +4 -0
  22. data/proto_docs/google/api/field_behavior.rb +59 -0
  23. data/proto_docs/google/api/resource.rb +247 -0
  24. data/proto_docs/google/protobuf/any.rb +138 -0
  25. data/proto_docs/google/protobuf/duration.rb +98 -0
  26. data/proto_docs/google/protobuf/empty.rb +36 -0
  27. data/proto_docs/google/protobuf/struct.rb +96 -0
  28. data/proto_docs/google/protobuf/timestamp.rb +120 -0
  29. data/proto_docs/google/rpc/status.rb +46 -0
  30. data/proto_docs/google/spanner/v1/keys.rb +162 -0
  31. data/proto_docs/google/spanner/v1/mutation.rb +110 -0
  32. data/proto_docs/google/spanner/v1/query_plan.rb +148 -0
  33. data/proto_docs/google/spanner/v1/result_set.rb +208 -0
  34. data/proto_docs/google/spanner/v1/spanner.rb +681 -0
  35. data/proto_docs/google/spanner/v1/transaction.rb +457 -0
  36. data/proto_docs/google/spanner/v1/type.rb +127 -0
  37. metadata +218 -0
@@ -0,0 +1,457 @@
1
+ # frozen_string_literal: true
2
+
3
+ # Copyright 2020 Google LLC
4
+ #
5
+ # Licensed under the Apache License, Version 2.0 (the "License");
6
+ # you may not use this file except in compliance with the License.
7
+ # You may obtain a copy of the License at
8
+ #
9
+ # https://www.apache.org/licenses/LICENSE-2.0
10
+ #
11
+ # Unless required by applicable law or agreed to in writing, software
12
+ # distributed under the License is distributed on an "AS IS" BASIS,
13
+ # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
14
+ # See the License for the specific language governing permissions and
15
+ # limitations under the License.
16
+
17
+ # Auto-generated by gapic-generator-ruby. DO NOT EDIT!
18
+
19
+
20
+ module Google
21
+ module Cloud
22
+ module Spanner
23
+ module V1
24
+ # # Transactions
25
+ #
26
+ #
27
+ # Each session can have at most one active transaction at a time. After the
28
+ # active transaction is completed, the session can immediately be
29
+ # re-used for the next transaction. It is not necessary to create a
30
+ # new session for each transaction.
31
+ #
32
+ # # Transaction Modes
33
+ #
34
+ # Cloud Spanner supports three transaction modes:
35
+ #
36
+ # 1. Locking read-write. This type of transaction is the only way
37
+ # to write data into Cloud Spanner. These transactions rely on
38
+ # pessimistic locking and, if necessary, two-phase commit.
39
+ # Locking read-write transactions may abort, requiring the
40
+ # application to retry.
41
+ #
42
+ # 2. Snapshot read-only. This transaction type provides guaranteed
43
+ # consistency across several reads, but does not allow
44
+ # writes. Snapshot read-only transactions can be configured to
45
+ # read at timestamps in the past. Snapshot read-only
46
+ # transactions do not need to be committed.
47
+ #
48
+ # 3. Partitioned DML. This type of transaction is used to execute
49
+ # a single Partitioned DML statement. Partitioned DML partitions
50
+ # the key space and runs the DML statement over each partition
51
+ # in parallel using separate, internal transactions that commit
52
+ # independently. Partitioned DML transactions do not need to be
53
+ # committed.
54
+ #
55
+ # For transactions that only read, snapshot read-only transactions
56
+ # provide simpler semantics and are almost always faster. In
57
+ # particular, read-only transactions do not take locks, so they do
58
+ # not conflict with read-write transactions. As a consequence of not
59
+ # taking locks, they also do not abort, so retry loops are not needed.
60
+ #
61
+ # Transactions may only read/write data in a single database. They
62
+ # may, however, read/write data in different tables within that
63
+ # database.
64
+ #
65
+ # ## Locking Read-Write Transactions
66
+ #
67
+ # Locking transactions may be used to atomically read-modify-write
68
+ # data anywhere in a database. This type of transaction is externally
69
+ # consistent.
70
+ #
71
+ # Clients should attempt to minimize the amount of time a transaction
72
+ # is active. Faster transactions commit with higher probability
73
+ # and cause less contention. Cloud Spanner attempts to keep read locks
74
+ # active as long as the transaction continues to do reads, and the
75
+ # transaction has not been terminated by
76
+ # {::Google::Cloud::Spanner::V1::Spanner::Client#commit Commit} or
77
+ # {::Google::Cloud::Spanner::V1::Spanner::Client#rollback Rollback}. Long periods of
78
+ # inactivity at the client may cause Cloud Spanner to release a
79
+ # transaction's locks and abort it.
80
+ #
81
+ # Conceptually, a read-write transaction consists of zero or more
82
+ # reads or SQL statements followed by
83
+ # {::Google::Cloud::Spanner::V1::Spanner::Client#commit Commit}. At any time before
84
+ # {::Google::Cloud::Spanner::V1::Spanner::Client#commit Commit}, the client can send a
85
+ # {::Google::Cloud::Spanner::V1::Spanner::Client#rollback Rollback} request to abort the
86
+ # transaction.
87
+ #
88
+ # ### Semantics
89
+ #
90
+ # Cloud Spanner can commit the transaction if all read locks it acquired
91
+ # are still valid at commit time, and it is able to acquire write
92
+ # locks for all writes. Cloud Spanner can abort the transaction for any
93
+ # reason. If a commit attempt returns `ABORTED`, Cloud Spanner guarantees
94
+ # that the transaction has not modified any user data in Cloud Spanner.
95
+ #
96
+ # Unless the transaction commits, Cloud Spanner makes no guarantees about
97
+ # how long the transaction's locks were held for. It is an error to
98
+ # use Cloud Spanner locks for any sort of mutual exclusion other than
99
+ # between Cloud Spanner transactions themselves.
100
+ #
101
+ # ### Retrying Aborted Transactions
102
+ #
103
+ # When a transaction aborts, the application can choose to retry the
104
+ # whole transaction again. To maximize the chances of successfully
105
+ # committing the retry, the client should execute the retry in the
106
+ # same session as the original attempt. The original session's lock
107
+ # priority increases with each consecutive abort, meaning that each
108
+ # attempt has a slightly better chance of success than the previous.
109
+ #
110
+ # Under some circumstances (e.g., many transactions attempting to
111
+ # modify the same row(s)), a transaction can abort many times in a
112
+ # short period before successfully committing. Thus, it is not a good
113
+ # idea to cap the number of retries a transaction can attempt;
114
+ # instead, it is better to limit the total amount of wall time spent
115
+ # retrying.
116
+ #
117
+ # ### Idle Transactions
118
+ #
119
+ # A transaction is considered idle if it has no outstanding reads or
120
+ # SQL queries and has not started a read or SQL query within the last 10
121
+ # seconds. Idle transactions can be aborted by Cloud Spanner so that they
122
+ # don't hold on to locks indefinitely. In that case, the commit will
123
+ # fail with error `ABORTED`.
124
+ #
125
+ # If this behavior is undesirable, periodically executing a simple
126
+ # SQL query in the transaction (e.g., `SELECT 1`) prevents the
127
+ # transaction from becoming idle.
128
+ #
129
+ # ## Snapshot Read-Only Transactions
130
+ #
131
+ # Snapshot read-only transactions provides a simpler method than
132
+ # locking read-write transactions for doing several consistent
133
+ # reads. However, this type of transaction does not support writes.
134
+ #
135
+ # Snapshot transactions do not take locks. Instead, they work by
136
+ # choosing a Cloud Spanner timestamp, then executing all reads at that
137
+ # timestamp. Since they do not acquire locks, they do not block
138
+ # concurrent read-write transactions.
139
+ #
140
+ # Unlike locking read-write transactions, snapshot read-only
141
+ # transactions never abort. They can fail if the chosen read
142
+ # timestamp is garbage collected; however, the default garbage
143
+ # collection policy is generous enough that most applications do not
144
+ # need to worry about this in practice.
145
+ #
146
+ # Snapshot read-only transactions do not need to call
147
+ # {::Google::Cloud::Spanner::V1::Spanner::Client#commit Commit} or
148
+ # {::Google::Cloud::Spanner::V1::Spanner::Client#rollback Rollback} (and in fact are not
149
+ # permitted to do so).
150
+ #
151
+ # To execute a snapshot transaction, the client specifies a timestamp
152
+ # bound, which tells Cloud Spanner how to choose a read timestamp.
153
+ #
154
+ # The types of timestamp bound are:
155
+ #
156
+ # - Strong (the default).
157
+ # - Bounded staleness.
158
+ # - Exact staleness.
159
+ #
160
+ # If the Cloud Spanner database to be read is geographically distributed,
161
+ # stale read-only transactions can execute more quickly than strong
162
+ # or read-write transaction, because they are able to execute far
163
+ # from the leader replica.
164
+ #
165
+ # Each type of timestamp bound is discussed in detail below.
166
+ #
167
+ # ### Strong
168
+ #
169
+ # Strong reads are guaranteed to see the effects of all transactions
170
+ # that have committed before the start of the read. Furthermore, all
171
+ # rows yielded by a single read are consistent with each other -- if
172
+ # any part of the read observes a transaction, all parts of the read
173
+ # see the transaction.
174
+ #
175
+ # Strong reads are not repeatable: two consecutive strong read-only
176
+ # transactions might return inconsistent results if there are
177
+ # concurrent writes. If consistency across reads is required, the
178
+ # reads should be executed within a transaction or at an exact read
179
+ # timestamp.
180
+ #
181
+ # See {::Google::Cloud::Spanner::V1::TransactionOptions::ReadOnly#strong TransactionOptions.ReadOnly.strong}.
182
+ #
183
+ # ### Exact Staleness
184
+ #
185
+ # These timestamp bounds execute reads at a user-specified
186
+ # timestamp. Reads at a timestamp are guaranteed to see a consistent
187
+ # prefix of the global transaction history: they observe
188
+ # modifications done by all transactions with a commit timestamp <=
189
+ # the read timestamp, and observe none of the modifications done by
190
+ # transactions with a larger commit timestamp. They will block until
191
+ # all conflicting transactions that may be assigned commit timestamps
192
+ # <= the read timestamp have finished.
193
+ #
194
+ # The timestamp can either be expressed as an absolute Cloud Spanner commit
195
+ # timestamp or a staleness relative to the current time.
196
+ #
197
+ # These modes do not require a "negotiation phase" to pick a
198
+ # timestamp. As a result, they execute slightly faster than the
199
+ # equivalent boundedly stale concurrency modes. On the other hand,
200
+ # boundedly stale reads usually return fresher results.
201
+ #
202
+ # See {::Google::Cloud::Spanner::V1::TransactionOptions::ReadOnly#read_timestamp TransactionOptions.ReadOnly.read_timestamp} and
203
+ # {::Google::Cloud::Spanner::V1::TransactionOptions::ReadOnly#exact_staleness TransactionOptions.ReadOnly.exact_staleness}.
204
+ #
205
+ # ### Bounded Staleness
206
+ #
207
+ # Bounded staleness modes allow Cloud Spanner to pick the read timestamp,
208
+ # subject to a user-provided staleness bound. Cloud Spanner chooses the
209
+ # newest timestamp within the staleness bound that allows execution
210
+ # of the reads at the closest available replica without blocking.
211
+ #
212
+ # All rows yielded are consistent with each other -- if any part of
213
+ # the read observes a transaction, all parts of the read see the
214
+ # transaction. Boundedly stale reads are not repeatable: two stale
215
+ # reads, even if they use the same staleness bound, can execute at
216
+ # different timestamps and thus return inconsistent results.
217
+ #
218
+ # Boundedly stale reads execute in two phases: the first phase
219
+ # negotiates a timestamp among all replicas needed to serve the
220
+ # read. In the second phase, reads are executed at the negotiated
221
+ # timestamp.
222
+ #
223
+ # As a result of the two phase execution, bounded staleness reads are
224
+ # usually a little slower than comparable exact staleness
225
+ # reads. However, they are typically able to return fresher
226
+ # results, and are more likely to execute at the closest replica.
227
+ #
228
+ # Because the timestamp negotiation requires up-front knowledge of
229
+ # which rows will be read, it can only be used with single-use
230
+ # read-only transactions.
231
+ #
232
+ # See {::Google::Cloud::Spanner::V1::TransactionOptions::ReadOnly#max_staleness TransactionOptions.ReadOnly.max_staleness} and
233
+ # {::Google::Cloud::Spanner::V1::TransactionOptions::ReadOnly#min_read_timestamp TransactionOptions.ReadOnly.min_read_timestamp}.
234
+ #
235
+ # ### Old Read Timestamps and Garbage Collection
236
+ #
237
+ # Cloud Spanner continuously garbage collects deleted and overwritten data
238
+ # in the background to reclaim storage space. This process is known
239
+ # as "version GC". By default, version GC reclaims versions after they
240
+ # are one hour old. Because of this, Cloud Spanner cannot perform reads
241
+ # at read timestamps more than one hour in the past. This
242
+ # restriction also applies to in-progress reads and/or SQL queries whose
243
+ # timestamp become too old while executing. Reads and SQL queries with
244
+ # too-old read timestamps fail with the error `FAILED_PRECONDITION`.
245
+ #
246
+ # ## Partitioned DML Transactions
247
+ #
248
+ # Partitioned DML transactions are used to execute DML statements with a
249
+ # different execution strategy that provides different, and often better,
250
+ # scalability properties for large, table-wide operations than DML in a
251
+ # ReadWrite transaction. Smaller scoped statements, such as an OLTP workload,
252
+ # should prefer using ReadWrite transactions.
253
+ #
254
+ # Partitioned DML partitions the keyspace and runs the DML statement on each
255
+ # partition in separate, internal transactions. These transactions commit
256
+ # automatically when complete, and run independently from one another.
257
+ #
258
+ # To reduce lock contention, this execution strategy only acquires read locks
259
+ # on rows that match the WHERE clause of the statement. Additionally, the
260
+ # smaller per-partition transactions hold locks for less time.
261
+ #
262
+ # That said, Partitioned DML is not a drop-in replacement for standard DML used
263
+ # in ReadWrite transactions.
264
+ #
265
+ # - The DML statement must be fully-partitionable. Specifically, the statement
266
+ # must be expressible as the union of many statements which each access only
267
+ # a single row of the table.
268
+ #
269
+ # - The statement is not applied atomically to all rows of the table. Rather,
270
+ # the statement is applied atomically to partitions of the table, in
271
+ # independent transactions. Secondary index rows are updated atomically
272
+ # with the base table rows.
273
+ #
274
+ # - Partitioned DML does not guarantee exactly-once execution semantics
275
+ # against a partition. The statement will be applied at least once to each
276
+ # partition. It is strongly recommended that the DML statement should be
277
+ # idempotent to avoid unexpected results. For instance, it is potentially
278
+ # dangerous to run a statement such as
279
+ # `UPDATE table SET column = column + 1` as it could be run multiple times
280
+ # against some rows.
281
+ #
282
+ # - The partitions are committed automatically - there is no support for
283
+ # Commit or Rollback. If the call returns an error, or if the client issuing
284
+ # the ExecuteSql call dies, it is possible that some rows had the statement
285
+ # executed on them successfully. It is also possible that statement was
286
+ # never executed against other rows.
287
+ #
288
+ # - Partitioned DML transactions may only contain the execution of a single
289
+ # DML statement via ExecuteSql or ExecuteStreamingSql.
290
+ #
291
+ # - If any error is encountered during the execution of the partitioned DML
292
+ # operation (for instance, a UNIQUE INDEX violation, division by zero, or a
293
+ # value that cannot be stored due to schema constraints), then the
294
+ # operation is stopped at that point and an error is returned. It is
295
+ # possible that at this point, some partitions have been committed (or even
296
+ # committed multiple times), and other partitions have not been run at all.
297
+ #
298
+ # Given the above, Partitioned DML is good fit for large, database-wide,
299
+ # operations that are idempotent, such as deleting old rows from a very large
300
+ # table.
301
+ # @!attribute [rw] read_write
302
+ # @return [::Google::Cloud::Spanner::V1::TransactionOptions::ReadWrite]
303
+ # Transaction may write.
304
+ #
305
+ # Authorization to begin a read-write transaction requires
306
+ # `spanner.databases.beginOrRollbackReadWriteTransaction` permission
307
+ # on the `session` resource.
308
+ # @!attribute [rw] partitioned_dml
309
+ # @return [::Google::Cloud::Spanner::V1::TransactionOptions::PartitionedDml]
310
+ # Partitioned DML transaction.
311
+ #
312
+ # Authorization to begin a Partitioned DML transaction requires
313
+ # `spanner.databases.beginPartitionedDmlTransaction` permission
314
+ # on the `session` resource.
315
+ # @!attribute [rw] read_only
316
+ # @return [::Google::Cloud::Spanner::V1::TransactionOptions::ReadOnly]
317
+ # Transaction will not write.
318
+ #
319
+ # Authorization to begin a read-only transaction requires
320
+ # `spanner.databases.beginReadOnlyTransaction` permission
321
+ # on the `session` resource.
322
+ class TransactionOptions
323
+ include ::Google::Protobuf::MessageExts
324
+ extend ::Google::Protobuf::MessageExts::ClassMethods
325
+
326
+ # Message type to initiate a read-write transaction. Currently this
327
+ # transaction type has no options.
328
+ class ReadWrite
329
+ include ::Google::Protobuf::MessageExts
330
+ extend ::Google::Protobuf::MessageExts::ClassMethods
331
+ end
332
+
333
+ # Message type to initiate a Partitioned DML transaction.
334
+ class PartitionedDml
335
+ include ::Google::Protobuf::MessageExts
336
+ extend ::Google::Protobuf::MessageExts::ClassMethods
337
+ end
338
+
339
+ # Message type to initiate a read-only transaction.
340
+ # @!attribute [rw] strong
341
+ # @return [::Boolean]
342
+ # Read at a timestamp where all previously committed transactions
343
+ # are visible.
344
+ # @!attribute [rw] min_read_timestamp
345
+ # @return [::Google::Protobuf::Timestamp]
346
+ # Executes all reads at a timestamp >= `min_read_timestamp`.
347
+ #
348
+ # This is useful for requesting fresher data than some previous
349
+ # read, or data that is fresh enough to observe the effects of some
350
+ # previously committed transaction whose timestamp is known.
351
+ #
352
+ # Note that this option can only be used in single-use transactions.
353
+ #
354
+ # A timestamp in RFC3339 UTC \"Zulu\" format, accurate to nanoseconds.
355
+ # Example: `"2014-10-02T15:01:23.045123456Z"`.
356
+ # @!attribute [rw] max_staleness
357
+ # @return [::Google::Protobuf::Duration]
358
+ # Read data at a timestamp >= `NOW - max_staleness`
359
+ # seconds. Guarantees that all writes that have committed more
360
+ # than the specified number of seconds ago are visible. Because
361
+ # Cloud Spanner chooses the exact timestamp, this mode works even if
362
+ # the client's local clock is substantially skewed from Cloud Spanner
363
+ # commit timestamps.
364
+ #
365
+ # Useful for reading the freshest data available at a nearby
366
+ # replica, while bounding the possible staleness if the local
367
+ # replica has fallen behind.
368
+ #
369
+ # Note that this option can only be used in single-use
370
+ # transactions.
371
+ # @!attribute [rw] read_timestamp
372
+ # @return [::Google::Protobuf::Timestamp]
373
+ # Executes all reads at the given timestamp. Unlike other modes,
374
+ # reads at a specific timestamp are repeatable; the same read at
375
+ # the same timestamp always returns the same data. If the
376
+ # timestamp is in the future, the read will block until the
377
+ # specified timestamp, modulo the read's deadline.
378
+ #
379
+ # Useful for large scale consistent reads such as mapreduces, or
380
+ # for coordinating many reads against a consistent snapshot of the
381
+ # data.
382
+ #
383
+ # A timestamp in RFC3339 UTC \"Zulu\" format, accurate to nanoseconds.
384
+ # Example: `"2014-10-02T15:01:23.045123456Z"`.
385
+ # @!attribute [rw] exact_staleness
386
+ # @return [::Google::Protobuf::Duration]
387
+ # Executes all reads at a timestamp that is `exact_staleness`
388
+ # old. The timestamp is chosen soon after the read is started.
389
+ #
390
+ # Guarantees that all writes that have committed more than the
391
+ # specified number of seconds ago are visible. Because Cloud Spanner
392
+ # chooses the exact timestamp, this mode works even if the client's
393
+ # local clock is substantially skewed from Cloud Spanner commit
394
+ # timestamps.
395
+ #
396
+ # Useful for reading at nearby replicas without the distributed
397
+ # timestamp negotiation overhead of `max_staleness`.
398
+ # @!attribute [rw] return_read_timestamp
399
+ # @return [::Boolean]
400
+ # If true, the Cloud Spanner-selected read timestamp is included in
401
+ # the {::Google::Cloud::Spanner::V1::Transaction Transaction} message that describes the transaction.
402
+ class ReadOnly
403
+ include ::Google::Protobuf::MessageExts
404
+ extend ::Google::Protobuf::MessageExts::ClassMethods
405
+ end
406
+ end
407
+
408
+ # A transaction.
409
+ # @!attribute [rw] id
410
+ # @return [::String]
411
+ # `id` may be used to identify the transaction in subsequent
412
+ # {::Google::Cloud::Spanner::V1::Spanner::Client#read Read},
413
+ # {::Google::Cloud::Spanner::V1::Spanner::Client#execute_sql ExecuteSql},
414
+ # {::Google::Cloud::Spanner::V1::Spanner::Client#commit Commit}, or
415
+ # {::Google::Cloud::Spanner::V1::Spanner::Client#rollback Rollback} calls.
416
+ #
417
+ # Single-use read-only transactions do not have IDs, because
418
+ # single-use transactions do not support multiple requests.
419
+ # @!attribute [rw] read_timestamp
420
+ # @return [::Google::Protobuf::Timestamp]
421
+ # For snapshot read-only transactions, the read timestamp chosen
422
+ # for the transaction. Not returned by default: see
423
+ # {::Google::Cloud::Spanner::V1::TransactionOptions::ReadOnly#return_read_timestamp TransactionOptions.ReadOnly.return_read_timestamp}.
424
+ #
425
+ # A timestamp in RFC3339 UTC \"Zulu\" format, accurate to nanoseconds.
426
+ # Example: `"2014-10-02T15:01:23.045123456Z"`.
427
+ class Transaction
428
+ include ::Google::Protobuf::MessageExts
429
+ extend ::Google::Protobuf::MessageExts::ClassMethods
430
+ end
431
+
432
+ # This message is used to select the transaction in which a
433
+ # {::Google::Cloud::Spanner::V1::Spanner::Client#read Read} or
434
+ # {::Google::Cloud::Spanner::V1::Spanner::Client#execute_sql ExecuteSql} call runs.
435
+ #
436
+ # See {::Google::Cloud::Spanner::V1::TransactionOptions TransactionOptions} for more information about transactions.
437
+ # @!attribute [rw] single_use
438
+ # @return [::Google::Cloud::Spanner::V1::TransactionOptions]
439
+ # Execute the read or SQL query in a temporary transaction.
440
+ # This is the most efficient way to execute a transaction that
441
+ # consists of a single SQL query.
442
+ # @!attribute [rw] id
443
+ # @return [::String]
444
+ # Execute the read or SQL query in a previously-started transaction.
445
+ # @!attribute [rw] begin
446
+ # @return [::Google::Cloud::Spanner::V1::TransactionOptions]
447
+ # Begin a new transaction and execute this read or SQL query in
448
+ # it. The transaction ID of the new transaction is returned in
449
+ # {::Google::Cloud::Spanner::V1::ResultSetMetadata#transaction ResultSetMetadata.transaction}, which is a {::Google::Cloud::Spanner::V1::Transaction Transaction}.
450
+ class TransactionSelector
451
+ include ::Google::Protobuf::MessageExts
452
+ extend ::Google::Protobuf::MessageExts::ClassMethods
453
+ end
454
+ end
455
+ end
456
+ end
457
+ end