Class: Google::Cloud::Spanner::V1::ReadRequest

Inherits:

Object

Object
Google::Cloud::Spanner::V1::ReadRequest

show all

Extended by:: Protobuf::MessageExts::ClassMethods

Includes:: Protobuf::MessageExts

Defined in:: proto_docs/google/spanner/v1/spanner.rb

Overview

The request for Read and StreamingRead.

Defined Under Namespace

Modules: LockHint, OrderBy

Instance Attribute Summary collapse

#columns ⇒ ::Array<::String>
Required.
#data_boost_enabled ⇒ ::Boolean
If this is for a partitioned read and this field is set to true, the request is executed with Spanner Data Boost independent compute resources.
#directed_read_options ⇒ ::Google::Cloud::Spanner::V1::DirectedReadOptions
Directed read options for this request.
#index ⇒ ::String
If non-empty, the name of an index on table.
#key_set ⇒ ::Google::Cloud::Spanner::V1::KeySet
Required.
#limit ⇒ ::Integer
If greater than zero, only the first limit rows are yielded.
#lock_hint ⇒ ::Google::Cloud::Spanner::V1::ReadRequest::LockHint
Optional.
#order_by ⇒ ::Google::Cloud::Spanner::V1::ReadRequest::OrderBy
Optional.
#partition_token ⇒ ::String
If present, results will be restricted to the specified partition previously created using PartitionRead().
#request_options ⇒ ::Google::Cloud::Spanner::V1::RequestOptions
Common options for this request.
#resume_token ⇒ ::String
If this request is resuming a previously interrupted read, resume_token should be copied from the last PartialResultSet yielded before the interruption.
#session ⇒ ::String
Required.
#table ⇒ ::String
Required.
#transaction ⇒ ::Google::Cloud::Spanner::V1::TransactionSelector
The transaction to use.

Instance Attribute Details

#columns ⇒ `::Array<::String>`

Required. The columns of table to be returned for each row matching this request.

Returns:

(::Array<::String>) —
Required. The columns of table to be returned for each row matching this request.

# File 'proto_docs/google/spanner/v1/spanner.rb', line 905

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # Acquire shared locks.
    #
    # By default when you perform a read as part of a read-write transaction,
    # Spanner acquires shared read locks, which allows other reads to still
    # access the data until your transaction is ready to commit. When your
    # transaction is committing and writes are being applied, the transaction
    # attempts to upgrade to an exclusive lock for any data you are writing.
    # For more information about locks, see [Lock
    # modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
    LOCK_HINT_SHARED = 1

    # Acquire exclusive locks.
    #
    # Requesting exclusive locks is beneficial if you observe high write
    # contention, which means you notice that multiple transactions are
    # concurrently trying to read and write to the same data, resulting in a
    # large number of aborts. This problem occurs when two transactions
    # initially acquire shared locks and then both try to upgrade to exclusive
    # locks at the same time. In this situation both transactions are waiting
    # for the other to give up their lock, resulting in a deadlocked situation.
    # Spanner is able to detect this occurring and force one of the
    # transactions to abort. However, this is a slow and expensive operation
    # and results in lower performance. In this case it makes sense to acquire
    # exclusive locks at the start of the transaction because then when
    # multiple transactions try to act on the same data, they automatically get
    # serialized. Each transaction waits its turn to acquire the lock and
    # avoids getting into deadlock situations.
    #
    # Because the exclusive lock hint is just a hint, it should not be
    # considered equivalent to a mutex. In other words, you should not use
    # Spanner exclusive locks as a mutual exclusion mechanism for the execution
    # of code outside of Spanner.
    #
    # **Note:** Request exclusive locks judiciously because they block others
    # from reading that data for the entire transaction, rather than just when
    # the writes are being performed. Unless you observe high write contention,
    # you should use the default of shared read locks so you don't prematurely
    # block other clients from reading the data that you're writing to.
    LOCK_HINT_EXCLUSIVE = 2
  end
end

#data_boost_enabled ⇒ `::Boolean`

Returns If this is for a partitioned read and this field is set to true, the request is executed with Spanner Data Boost independent compute resources.

If the field is set to true but the request does not set partition_token, the API returns an INVALID_ARGUMENT error.

Returns:

(::Boolean) —
If this is for a partitioned read and this field is set to true, the request is executed with Spanner Data Boost independent compute resources.

If the field is set to true but the request does not set partition_token, the API returns an INVALID_ARGUMENT error.

# File 'proto_docs/google/spanner/v1/spanner.rb', line 905

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # Acquire shared locks.
    #
    # By default when you perform a read as part of a read-write transaction,
    # Spanner acquires shared read locks, which allows other reads to still
    # access the data until your transaction is ready to commit. When your
    # transaction is committing and writes are being applied, the transaction
    # attempts to upgrade to an exclusive lock for any data you are writing.
    # For more information about locks, see [Lock
    # modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
    LOCK_HINT_SHARED = 1

    # Acquire exclusive locks.
    #
    # Requesting exclusive locks is beneficial if you observe high write
    # contention, which means you notice that multiple transactions are
    # concurrently trying to read and write to the same data, resulting in a
    # large number of aborts. This problem occurs when two transactions
    # initially acquire shared locks and then both try to upgrade to exclusive
    # locks at the same time. In this situation both transactions are waiting
    # for the other to give up their lock, resulting in a deadlocked situation.
    # Spanner is able to detect this occurring and force one of the
    # transactions to abort. However, this is a slow and expensive operation
    # and results in lower performance. In this case it makes sense to acquire
    # exclusive locks at the start of the transaction because then when
    # multiple transactions try to act on the same data, they automatically get
    # serialized. Each transaction waits its turn to acquire the lock and
    # avoids getting into deadlock situations.
    #
    # Because the exclusive lock hint is just a hint, it should not be
    # considered equivalent to a mutex. In other words, you should not use
    # Spanner exclusive locks as a mutual exclusion mechanism for the execution
    # of code outside of Spanner.
    #
    # **Note:** Request exclusive locks judiciously because they block others
    # from reading that data for the entire transaction, rather than just when
    # the writes are being performed. Unless you observe high write contention,
    # you should use the default of shared read locks so you don't prematurely
    # block other clients from reading the data that you're writing to.
    LOCK_HINT_EXCLUSIVE = 2
  end
end

#directed_read_options ⇒ `::Google::Cloud::Spanner::V1::DirectedReadOptions`

Returns Directed read options for this request.

Returns:

(::Google::Cloud::Spanner::V1::DirectedReadOptions) —
Directed read options for this request.

# File 'proto_docs/google/spanner/v1/spanner.rb', line 905

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # Acquire shared locks.
    #
    # By default when you perform a read as part of a read-write transaction,
    # Spanner acquires shared read locks, which allows other reads to still
    # access the data until your transaction is ready to commit. When your
    # transaction is committing and writes are being applied, the transaction
    # attempts to upgrade to an exclusive lock for any data you are writing.
    # For more information about locks, see [Lock
    # modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
    LOCK_HINT_SHARED = 1

    # Acquire exclusive locks.
    #
    # Requesting exclusive locks is beneficial if you observe high write
    # contention, which means you notice that multiple transactions are
    # concurrently trying to read and write to the same data, resulting in a
    # large number of aborts. This problem occurs when two transactions
    # initially acquire shared locks and then both try to upgrade to exclusive
    # locks at the same time. In this situation both transactions are waiting
    # for the other to give up their lock, resulting in a deadlocked situation.
    # Spanner is able to detect this occurring and force one of the
    # transactions to abort. However, this is a slow and expensive operation
    # and results in lower performance. In this case it makes sense to acquire
    # exclusive locks at the start of the transaction because then when
    # multiple transactions try to act on the same data, they automatically get
    # serialized. Each transaction waits its turn to acquire the lock and
    # avoids getting into deadlock situations.
    #
    # Because the exclusive lock hint is just a hint, it should not be
    # considered equivalent to a mutex. In other words, you should not use
    # Spanner exclusive locks as a mutual exclusion mechanism for the execution
    # of code outside of Spanner.
    #
    # **Note:** Request exclusive locks judiciously because they block others
    # from reading that data for the entire transaction, rather than just when
    # the writes are being performed. Unless you observe high write contention,
    # you should use the default of shared read locks so you don't prematurely
    # block other clients from reading the data that you're writing to.
    LOCK_HINT_EXCLUSIVE = 2
  end
end

#index ⇒ `::String`

Returns If non-empty, the name of an index on table. This index is used instead of the table primary key when interpreting key_set and sorting result rows. See key_set for further information.

Returns:

(::String) —
If non-empty, the name of an index on table. This index is used instead of the table primary key when interpreting key_set and sorting result rows. See key_set for further information.

# File 'proto_docs/google/spanner/v1/spanner.rb', line 905

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # Acquire shared locks.
    #
    # By default when you perform a read as part of a read-write transaction,
    # Spanner acquires shared read locks, which allows other reads to still
    # access the data until your transaction is ready to commit. When your
    # transaction is committing and writes are being applied, the transaction
    # attempts to upgrade to an exclusive lock for any data you are writing.
    # For more information about locks, see [Lock
    # modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
    LOCK_HINT_SHARED = 1

    # Acquire exclusive locks.
    #
    # Requesting exclusive locks is beneficial if you observe high write
    # contention, which means you notice that multiple transactions are
    # concurrently trying to read and write to the same data, resulting in a
    # large number of aborts. This problem occurs when two transactions
    # initially acquire shared locks and then both try to upgrade to exclusive
    # locks at the same time. In this situation both transactions are waiting
    # for the other to give up their lock, resulting in a deadlocked situation.
    # Spanner is able to detect this occurring and force one of the
    # transactions to abort. However, this is a slow and expensive operation
    # and results in lower performance. In this case it makes sense to acquire
    # exclusive locks at the start of the transaction because then when
    # multiple transactions try to act on the same data, they automatically get
    # serialized. Each transaction waits its turn to acquire the lock and
    # avoids getting into deadlock situations.
    #
    # Because the exclusive lock hint is just a hint, it should not be
    # considered equivalent to a mutex. In other words, you should not use
    # Spanner exclusive locks as a mutual exclusion mechanism for the execution
    # of code outside of Spanner.
    #
    # **Note:** Request exclusive locks judiciously because they block others
    # from reading that data for the entire transaction, rather than just when
    # the writes are being performed. Unless you observe high write contention,
    # you should use the default of shared read locks so you don't prematurely
    # block other clients from reading the data that you're writing to.
    LOCK_HINT_EXCLUSIVE = 2
  end
end

#key_set ⇒ `::Google::Cloud::Spanner::V1::KeySet`

Returns Required. key_set identifies the rows to be yielded. key_set names the primary keys of the rows in table to be yielded, unless index is present. If index is present, then key_set instead names index keys in index.

If the partition_token field is empty, rows are yielded in table primary key order (if index is empty) or index key order (if index is non-empty). If the partition_token field is not empty, rows will be yielded in an unspecified order.

It is not an error for the key_set to name rows that do not exist in the database. Read yields nothing for nonexistent rows.

Returns:

(::Google::Cloud::Spanner::V1::KeySet) —
Required. key_set identifies the rows to be yielded. key_set names the primary keys of the rows in table to be yielded, unless index is present. If index is present, then key_set instead names index keys in index.

If the partition_token field is empty, rows are yielded in table primary key order (if index is empty) or index key order (if index is non-empty). If the partition_token field is not empty, rows will be yielded in an unspecified order.

It is not an error for the key_set to name rows that do not exist in the database. Read yields nothing for nonexistent rows.

# File 'proto_docs/google/spanner/v1/spanner.rb', line 905

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # Acquire shared locks.
    #
    # By default when you perform a read as part of a read-write transaction,
    # Spanner acquires shared read locks, which allows other reads to still
    # access the data until your transaction is ready to commit. When your
    # transaction is committing and writes are being applied, the transaction
    # attempts to upgrade to an exclusive lock for any data you are writing.
    # For more information about locks, see [Lock
    # modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
    LOCK_HINT_SHARED = 1

    # Acquire exclusive locks.
    #
    # Requesting exclusive locks is beneficial if you observe high write
    # contention, which means you notice that multiple transactions are
    # concurrently trying to read and write to the same data, resulting in a
    # large number of aborts. This problem occurs when two transactions
    # initially acquire shared locks and then both try to upgrade to exclusive
    # locks at the same time. In this situation both transactions are waiting
    # for the other to give up their lock, resulting in a deadlocked situation.
    # Spanner is able to detect this occurring and force one of the
    # transactions to abort. However, this is a slow and expensive operation
    # and results in lower performance. In this case it makes sense to acquire
    # exclusive locks at the start of the transaction because then when
    # multiple transactions try to act on the same data, they automatically get
    # serialized. Each transaction waits its turn to acquire the lock and
    # avoids getting into deadlock situations.
    #
    # Because the exclusive lock hint is just a hint, it should not be
    # considered equivalent to a mutex. In other words, you should not use
    # Spanner exclusive locks as a mutual exclusion mechanism for the execution
    # of code outside of Spanner.
    #
    # **Note:** Request exclusive locks judiciously because they block others
    # from reading that data for the entire transaction, rather than just when
    # the writes are being performed. Unless you observe high write contention,
    # you should use the default of shared read locks so you don't prematurely
    # block other clients from reading the data that you're writing to.
    LOCK_HINT_EXCLUSIVE = 2
  end
end

#limit ⇒ `::Integer`

Returns If greater than zero, only the first limit rows are yielded. If limit is zero, the default is no limit. A limit cannot be specified if partition_token is set.

Returns:

(::Integer) —
If greater than zero, only the first limit rows are yielded. If limit is zero, the default is no limit. A limit cannot be specified if partition_token is set.

# File 'proto_docs/google/spanner/v1/spanner.rb', line 905

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # Acquire shared locks.
    #
    # By default when you perform a read as part of a read-write transaction,
    # Spanner acquires shared read locks, which allows other reads to still
    # access the data until your transaction is ready to commit. When your
    # transaction is committing and writes are being applied, the transaction
    # attempts to upgrade to an exclusive lock for any data you are writing.
    # For more information about locks, see [Lock
    # modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
    LOCK_HINT_SHARED = 1

    # Acquire exclusive locks.
    #
    # Requesting exclusive locks is beneficial if you observe high write
    # contention, which means you notice that multiple transactions are
    # concurrently trying to read and write to the same data, resulting in a
    # large number of aborts. This problem occurs when two transactions
    # initially acquire shared locks and then both try to upgrade to exclusive
    # locks at the same time. In this situation both transactions are waiting
    # for the other to give up their lock, resulting in a deadlocked situation.
    # Spanner is able to detect this occurring and force one of the
    # transactions to abort. However, this is a slow and expensive operation
    # and results in lower performance. In this case it makes sense to acquire
    # exclusive locks at the start of the transaction because then when
    # multiple transactions try to act on the same data, they automatically get
    # serialized. Each transaction waits its turn to acquire the lock and
    # avoids getting into deadlock situations.
    #
    # Because the exclusive lock hint is just a hint, it should not be
    # considered equivalent to a mutex. In other words, you should not use
    # Spanner exclusive locks as a mutual exclusion mechanism for the execution
    # of code outside of Spanner.
    #
    # **Note:** Request exclusive locks judiciously because they block others
    # from reading that data for the entire transaction, rather than just when
    # the writes are being performed. Unless you observe high write contention,
    # you should use the default of shared read locks so you don't prematurely
    # block other clients from reading the data that you're writing to.
    LOCK_HINT_EXCLUSIVE = 2
  end
end

#lock_hint ⇒ `::Google::Cloud::Spanner::V1::ReadRequest::LockHint`

Returns Optional. Lock Hint for the request, it can only be used with read-write transactions.

Returns:

(::Google::Cloud::Spanner::V1::ReadRequest::LockHint) —
Optional. Lock Hint for the request, it can only be used with read-write transactions.

# File 'proto_docs/google/spanner/v1/spanner.rb', line 905

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # Acquire shared locks.
    #
    # By default when you perform a read as part of a read-write transaction,
    # Spanner acquires shared read locks, which allows other reads to still
    # access the data until your transaction is ready to commit. When your
    # transaction is committing and writes are being applied, the transaction
    # attempts to upgrade to an exclusive lock for any data you are writing.
    # For more information about locks, see [Lock
    # modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
    LOCK_HINT_SHARED = 1

    # Acquire exclusive locks.
    #
    # Requesting exclusive locks is beneficial if you observe high write
    # contention, which means you notice that multiple transactions are
    # concurrently trying to read and write to the same data, resulting in a
    # large number of aborts. This problem occurs when two transactions
    # initially acquire shared locks and then both try to upgrade to exclusive
    # locks at the same time. In this situation both transactions are waiting
    # for the other to give up their lock, resulting in a deadlocked situation.
    # Spanner is able to detect this occurring and force one of the
    # transactions to abort. However, this is a slow and expensive operation
    # and results in lower performance. In this case it makes sense to acquire
    # exclusive locks at the start of the transaction because then when
    # multiple transactions try to act on the same data, they automatically get
    # serialized. Each transaction waits its turn to acquire the lock and
    # avoids getting into deadlock situations.
    #
    # Because the exclusive lock hint is just a hint, it should not be
    # considered equivalent to a mutex. In other words, you should not use
    # Spanner exclusive locks as a mutual exclusion mechanism for the execution
    # of code outside of Spanner.
    #
    # **Note:** Request exclusive locks judiciously because they block others
    # from reading that data for the entire transaction, rather than just when
    # the writes are being performed. Unless you observe high write contention,
    # you should use the default of shared read locks so you don't prematurely
    # block other clients from reading the data that you're writing to.
    LOCK_HINT_EXCLUSIVE = 2
  end
end

#order_by ⇒ `::Google::Cloud::Spanner::V1::ReadRequest::OrderBy`

Optional. Order for the returned rows.

By default, Spanner will return result rows in primary key order except for PartitionRead requests. For applications that do not require rows to be returned in primary key (ORDER_BY_PRIMARY_KEY) order, setting ORDER_BY_NO_ORDER option allows Spanner to optimize row retrieval, resulting in lower latencies in certain cases (e.g. bulk point lookups).

Returns:

(::Google::Cloud::Spanner::V1::ReadRequest::OrderBy) —
Optional. Order for the returned rows.

By default, Spanner will return result rows in primary key order except for PartitionRead requests. For applications that do not require rows to be returned in primary key (ORDER_BY_PRIMARY_KEY) order, setting ORDER_BY_NO_ORDER option allows Spanner to optimize row retrieval, resulting in lower latencies in certain cases (e.g. bulk point lookups).

# File 'proto_docs/google/spanner/v1/spanner.rb', line 905

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # Acquire shared locks.
    #
    # By default when you perform a read as part of a read-write transaction,
    # Spanner acquires shared read locks, which allows other reads to still
    # access the data until your transaction is ready to commit. When your
    # transaction is committing and writes are being applied, the transaction
    # attempts to upgrade to an exclusive lock for any data you are writing.
    # For more information about locks, see [Lock
    # modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
    LOCK_HINT_SHARED = 1

    # Acquire exclusive locks.
    #
    # Requesting exclusive locks is beneficial if you observe high write
    # contention, which means you notice that multiple transactions are
    # concurrently trying to read and write to the same data, resulting in a
    # large number of aborts. This problem occurs when two transactions
    # initially acquire shared locks and then both try to upgrade to exclusive
    # locks at the same time. In this situation both transactions are waiting
    # for the other to give up their lock, resulting in a deadlocked situation.
    # Spanner is able to detect this occurring and force one of the
    # transactions to abort. However, this is a slow and expensive operation
    # and results in lower performance. In this case it makes sense to acquire
    # exclusive locks at the start of the transaction because then when
    # multiple transactions try to act on the same data, they automatically get
    # serialized. Each transaction waits its turn to acquire the lock and
    # avoids getting into deadlock situations.
    #
    # Because the exclusive lock hint is just a hint, it should not be
    # considered equivalent to a mutex. In other words, you should not use
    # Spanner exclusive locks as a mutual exclusion mechanism for the execution
    # of code outside of Spanner.
    #
    # **Note:** Request exclusive locks judiciously because they block others
    # from reading that data for the entire transaction, rather than just when
    # the writes are being performed. Unless you observe high write contention,
    # you should use the default of shared read locks so you don't prematurely
    # block other clients from reading the data that you're writing to.
    LOCK_HINT_EXCLUSIVE = 2
  end
end

#partition_token ⇒ `::String`

Returns If present, results will be restricted to the specified partition previously created using PartitionRead(). There must be an exact match for the values of fields common to this message and the PartitionReadRequest message used to create this partition_token.

Returns:

(::String) —
If present, results will be restricted to the specified partition previously created using PartitionRead(). There must be an exact match for the values of fields common to this message and the PartitionReadRequest message used to create this partition_token.

# File 'proto_docs/google/spanner/v1/spanner.rb', line 905

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # Acquire shared locks.
    #
    # By default when you perform a read as part of a read-write transaction,
    # Spanner acquires shared read locks, which allows other reads to still
    # access the data until your transaction is ready to commit. When your
    # transaction is committing and writes are being applied, the transaction
    # attempts to upgrade to an exclusive lock for any data you are writing.
    # For more information about locks, see [Lock
    # modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
    LOCK_HINT_SHARED = 1

    # Acquire exclusive locks.
    #
    # Requesting exclusive locks is beneficial if you observe high write
    # contention, which means you notice that multiple transactions are
    # concurrently trying to read and write to the same data, resulting in a
    # large number of aborts. This problem occurs when two transactions
    # initially acquire shared locks and then both try to upgrade to exclusive
    # locks at the same time. In this situation both transactions are waiting
    # for the other to give up their lock, resulting in a deadlocked situation.
    # Spanner is able to detect this occurring and force one of the
    # transactions to abort. However, this is a slow and expensive operation
    # and results in lower performance. In this case it makes sense to acquire
    # exclusive locks at the start of the transaction because then when
    # multiple transactions try to act on the same data, they automatically get
    # serialized. Each transaction waits its turn to acquire the lock and
    # avoids getting into deadlock situations.
    #
    # Because the exclusive lock hint is just a hint, it should not be
    # considered equivalent to a mutex. In other words, you should not use
    # Spanner exclusive locks as a mutual exclusion mechanism for the execution
    # of code outside of Spanner.
    #
    # **Note:** Request exclusive locks judiciously because they block others
    # from reading that data for the entire transaction, rather than just when
    # the writes are being performed. Unless you observe high write contention,
    # you should use the default of shared read locks so you don't prematurely
    # block other clients from reading the data that you're writing to.
    LOCK_HINT_EXCLUSIVE = 2
  end
end

#request_options ⇒ `::Google::Cloud::Spanner::V1::RequestOptions`

Returns Common options for this request.

Returns:

(::Google::Cloud::Spanner::V1::RequestOptions) —
Common options for this request.

# File 'proto_docs/google/spanner/v1/spanner.rb', line 905

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # Acquire shared locks.
    #
    # By default when you perform a read as part of a read-write transaction,
    # Spanner acquires shared read locks, which allows other reads to still
    # access the data until your transaction is ready to commit. When your
    # transaction is committing and writes are being applied, the transaction
    # attempts to upgrade to an exclusive lock for any data you are writing.
    # For more information about locks, see [Lock
    # modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
    LOCK_HINT_SHARED = 1

    # Acquire exclusive locks.
    #
    # Requesting exclusive locks is beneficial if you observe high write
    # contention, which means you notice that multiple transactions are
    # concurrently trying to read and write to the same data, resulting in a
    # large number of aborts. This problem occurs when two transactions
    # initially acquire shared locks and then both try to upgrade to exclusive
    # locks at the same time. In this situation both transactions are waiting
    # for the other to give up their lock, resulting in a deadlocked situation.
    # Spanner is able to detect this occurring and force one of the
    # transactions to abort. However, this is a slow and expensive operation
    # and results in lower performance. In this case it makes sense to acquire
    # exclusive locks at the start of the transaction because then when
    # multiple transactions try to act on the same data, they automatically get
    # serialized. Each transaction waits its turn to acquire the lock and
    # avoids getting into deadlock situations.
    #
    # Because the exclusive lock hint is just a hint, it should not be
    # considered equivalent to a mutex. In other words, you should not use
    # Spanner exclusive locks as a mutual exclusion mechanism for the execution
    # of code outside of Spanner.
    #
    # **Note:** Request exclusive locks judiciously because they block others
    # from reading that data for the entire transaction, rather than just when
    # the writes are being performed. Unless you observe high write contention,
    # you should use the default of shared read locks so you don't prematurely
    # block other clients from reading the data that you're writing to.
    LOCK_HINT_EXCLUSIVE = 2
  end
end

#resume_token ⇒ `::String`

Returns If this request is resuming a previously interrupted read, resume_token should be copied from the last PartialResultSet yielded before the interruption. Doing this enables the new read to resume where the last read left off. The rest of the request parameters must exactly match the request that yielded this token.

Returns:

(::String) —
If this request is resuming a previously interrupted read, resume_token should be copied from the last PartialResultSet yielded before the interruption. Doing this enables the new read to resume where the last read left off. The rest of the request parameters must exactly match the request that yielded this token.

# File 'proto_docs/google/spanner/v1/spanner.rb', line 905

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # Acquire shared locks.
    #
    # By default when you perform a read as part of a read-write transaction,
    # Spanner acquires shared read locks, which allows other reads to still
    # access the data until your transaction is ready to commit. When your
    # transaction is committing and writes are being applied, the transaction
    # attempts to upgrade to an exclusive lock for any data you are writing.
    # For more information about locks, see [Lock
    # modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
    LOCK_HINT_SHARED = 1

    # Acquire exclusive locks.
    #
    # Requesting exclusive locks is beneficial if you observe high write
    # contention, which means you notice that multiple transactions are
    # concurrently trying to read and write to the same data, resulting in a
    # large number of aborts. This problem occurs when two transactions
    # initially acquire shared locks and then both try to upgrade to exclusive
    # locks at the same time. In this situation both transactions are waiting
    # for the other to give up their lock, resulting in a deadlocked situation.
    # Spanner is able to detect this occurring and force one of the
    # transactions to abort. However, this is a slow and expensive operation
    # and results in lower performance. In this case it makes sense to acquire
    # exclusive locks at the start of the transaction because then when
    # multiple transactions try to act on the same data, they automatically get
    # serialized. Each transaction waits its turn to acquire the lock and
    # avoids getting into deadlock situations.
    #
    # Because the exclusive lock hint is just a hint, it should not be
    # considered equivalent to a mutex. In other words, you should not use
    # Spanner exclusive locks as a mutual exclusion mechanism for the execution
    # of code outside of Spanner.
    #
    # **Note:** Request exclusive locks judiciously because they block others
    # from reading that data for the entire transaction, rather than just when
    # the writes are being performed. Unless you observe high write contention,
    # you should use the default of shared read locks so you don't prematurely
    # block other clients from reading the data that you're writing to.
    LOCK_HINT_EXCLUSIVE = 2
  end
end

#session ⇒ `::String`

Returns Required. The session in which the read should be performed.

Returns:

(::String) —
Required. The session in which the read should be performed.

# File 'proto_docs/google/spanner/v1/spanner.rb', line 905

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # Acquire shared locks.
    #
    # By default when you perform a read as part of a read-write transaction,
    # Spanner acquires shared read locks, which allows other reads to still
    # access the data until your transaction is ready to commit. When your
    # transaction is committing and writes are being applied, the transaction
    # attempts to upgrade to an exclusive lock for any data you are writing.
    # For more information about locks, see [Lock
    # modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
    LOCK_HINT_SHARED = 1

    # Acquire exclusive locks.
    #
    # Requesting exclusive locks is beneficial if you observe high write
    # contention, which means you notice that multiple transactions are
    # concurrently trying to read and write to the same data, resulting in a
    # large number of aborts. This problem occurs when two transactions
    # initially acquire shared locks and then both try to upgrade to exclusive
    # locks at the same time. In this situation both transactions are waiting
    # for the other to give up their lock, resulting in a deadlocked situation.
    # Spanner is able to detect this occurring and force one of the
    # transactions to abort. However, this is a slow and expensive operation
    # and results in lower performance. In this case it makes sense to acquire
    # exclusive locks at the start of the transaction because then when
    # multiple transactions try to act on the same data, they automatically get
    # serialized. Each transaction waits its turn to acquire the lock and
    # avoids getting into deadlock situations.
    #
    # Because the exclusive lock hint is just a hint, it should not be
    # considered equivalent to a mutex. In other words, you should not use
    # Spanner exclusive locks as a mutual exclusion mechanism for the execution
    # of code outside of Spanner.
    #
    # **Note:** Request exclusive locks judiciously because they block others
    # from reading that data for the entire transaction, rather than just when
    # the writes are being performed. Unless you observe high write contention,
    # you should use the default of shared read locks so you don't prematurely
    # block other clients from reading the data that you're writing to.
    LOCK_HINT_EXCLUSIVE = 2
  end
end

#table ⇒ `::String`

Returns Required. The name of the table in the database to be read.

Returns:

(::String) —
Required. The name of the table in the database to be read.

# File 'proto_docs/google/spanner/v1/spanner.rb', line 905

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # Acquire shared locks.
    #
    # By default when you perform a read as part of a read-write transaction,
    # Spanner acquires shared read locks, which allows other reads to still
    # access the data until your transaction is ready to commit. When your
    # transaction is committing and writes are being applied, the transaction
    # attempts to upgrade to an exclusive lock for any data you are writing.
    # For more information about locks, see [Lock
    # modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
    LOCK_HINT_SHARED = 1

    # Acquire exclusive locks.
    #
    # Requesting exclusive locks is beneficial if you observe high write
    # contention, which means you notice that multiple transactions are
    # concurrently trying to read and write to the same data, resulting in a
    # large number of aborts. This problem occurs when two transactions
    # initially acquire shared locks and then both try to upgrade to exclusive
    # locks at the same time. In this situation both transactions are waiting
    # for the other to give up their lock, resulting in a deadlocked situation.
    # Spanner is able to detect this occurring and force one of the
    # transactions to abort. However, this is a slow and expensive operation
    # and results in lower performance. In this case it makes sense to acquire
    # exclusive locks at the start of the transaction because then when
    # multiple transactions try to act on the same data, they automatically get
    # serialized. Each transaction waits its turn to acquire the lock and
    # avoids getting into deadlock situations.
    #
    # Because the exclusive lock hint is just a hint, it should not be
    # considered equivalent to a mutex. In other words, you should not use
    # Spanner exclusive locks as a mutual exclusion mechanism for the execution
    # of code outside of Spanner.
    #
    # **Note:** Request exclusive locks judiciously because they block others
    # from reading that data for the entire transaction, rather than just when
    # the writes are being performed. Unless you observe high write contention,
    # you should use the default of shared read locks so you don't prematurely
    # block other clients from reading the data that you're writing to.
    LOCK_HINT_EXCLUSIVE = 2
  end
end

#transaction ⇒ `::Google::Cloud::Spanner::V1::TransactionSelector`

Returns The transaction to use. If none is provided, the default is a temporary read-only transaction with strong concurrency.

Returns:

(::Google::Cloud::Spanner::V1::TransactionSelector) —
The transaction to use. If none is provided, the default is a temporary read-only transaction with strong concurrency.

# File 'proto_docs/google/spanner/v1/spanner.rb', line 905

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # Acquire shared locks.
    #
    # By default when you perform a read as part of a read-write transaction,
    # Spanner acquires shared read locks, which allows other reads to still
    # access the data until your transaction is ready to commit. When your
    # transaction is committing and writes are being applied, the transaction
    # attempts to upgrade to an exclusive lock for any data you are writing.
    # For more information about locks, see [Lock
    # modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
    LOCK_HINT_SHARED = 1

    # Acquire exclusive locks.
    #
    # Requesting exclusive locks is beneficial if you observe high write
    # contention, which means you notice that multiple transactions are
    # concurrently trying to read and write to the same data, resulting in a
    # large number of aborts. This problem occurs when two transactions
    # initially acquire shared locks and then both try to upgrade to exclusive
    # locks at the same time. In this situation both transactions are waiting
    # for the other to give up their lock, resulting in a deadlocked situation.
    # Spanner is able to detect this occurring and force one of the
    # transactions to abort. However, this is a slow and expensive operation
    # and results in lower performance. In this case it makes sense to acquire
    # exclusive locks at the start of the transaction because then when
    # multiple transactions try to act on the same data, they automatically get
    # serialized. Each transaction waits its turn to acquire the lock and
    # avoids getting into deadlock situations.
    #
    # Because the exclusive lock hint is just a hint, it should not be
    # considered equivalent to a mutex. In other words, you should not use
    # Spanner exclusive locks as a mutual exclusion mechanism for the execution
    # of code outside of Spanner.
    #
    # **Note:** Request exclusive locks judiciously because they block others
    # from reading that data for the entire transaction, rather than just when
    # the writes are being performed. Unless you observe high write contention,
    # you should use the default of shared read locks so you don't prematurely
    # block other clients from reading the data that you're writing to.
    LOCK_HINT_EXCLUSIVE = 2
  end
end

Class: Google::Cloud::Spanner::V1::ReadRequest

Overview

Defined Under Namespace

Instance Attribute Summary collapse

Instance Attribute Details

#columns ⇒ ::Array<::String>

#data_boost_enabled ⇒ ::Boolean

#directed_read_options ⇒ ::Google::Cloud::Spanner::V1::DirectedReadOptions

#index ⇒ ::String

#key_set ⇒ ::Google::Cloud::Spanner::V1::KeySet

#limit ⇒ ::Integer

#lock_hint ⇒ ::Google::Cloud::Spanner::V1::ReadRequest::LockHint

#order_by ⇒ ::Google::Cloud::Spanner::V1::ReadRequest::OrderBy

#partition_token ⇒ ::String

#request_options ⇒ ::Google::Cloud::Spanner::V1::RequestOptions

#resume_token ⇒ ::String

#session ⇒ ::String

#table ⇒ ::String

#transaction ⇒ ::Google::Cloud::Spanner::V1::TransactionSelector

#columns ⇒ `::Array<::String>`

#data_boost_enabled ⇒ `::Boolean`

#directed_read_options ⇒ `::Google::Cloud::Spanner::V1::DirectedReadOptions`

#index ⇒ `::String`

#key_set ⇒ `::Google::Cloud::Spanner::V1::KeySet`

#limit ⇒ `::Integer`

#lock_hint ⇒ `::Google::Cloud::Spanner::V1::ReadRequest::LockHint`

#order_by ⇒ `::Google::Cloud::Spanner::V1::ReadRequest::OrderBy`

#partition_token ⇒ `::String`

#request_options ⇒ `::Google::Cloud::Spanner::V1::RequestOptions`

#resume_token ⇒ `::String`

#session ⇒ `::String`

#table ⇒ `::String`

#transaction ⇒ `::Google::Cloud::Spanner::V1::TransactionSelector`