Get desktop application:
View/edit binary Protocol Buffers messages
* Oxia service that allows clients to discover shard-to-server assignments and submit batches of requests. Clients should connect to a random server to discover the shard-to-server assignments and then send the actual batched requests to the appropriate shard leader. In the future, this may be handled server-side in a proxy layer to allows clients to not be concerned with sharding.
* Gets all shard-to-server assignments as a stream. Each set of assignments in the response stream will contain all the assignments to bring the client up to date. For example, if a shard is split, the stream will return a single response containing all the new shard assignments as opposed to multiple stream responses, each containing a single shard assignment. Clients should connect to a single random server which will stream the assignments for all shards on all servers.
* A shard assignments request. Gets all shard-to-server assignments as a stream. Each set of assignments in the response stream will contain all the assignments to bring the client up to date. For example, if a shard is split, the stream will return a single response containing all the new shard assignments as opposed to multiple stream responses, each containing a single shard assignment.
* Batches put, delete and delete_range requests. Clients should send this request to the shard leader. In the future, this may be handled server-side in a proxy layer. Deprecated
* Batches put, delete and delete_range requests. Clients should send this request to the shard leader. In the future, this may be handled server-side in a proxy layer.
* Batches get requests. Clients should send this request to the shard leader. In the future, this may be handled server-side in a proxy layer.
* A batch read request. Applies the batches of requests.
The shard id. This is optional allow for support for server-side hashing and proxying in the future.
The get requests
* The response to a batch read request. Responses of each type respect the order of the original requests.
The get responses
* Requests all the keys between a range of keys. Clients should send an equivalent request to all respective shards, unless a particular partition key was specified.
* Input to a list request. Key ranges assume a UTF-8 byte sort order.
The shard id. This is optional allow for support for server-side hashing and proxying in the future.
The start of the range, inclusive
The end of the range, exclusive
* The response to a list request.
A portion of the keys found within the specified range
* Requests all the records between a range of keys. Clients should send an equivalent request to all respective shards, unless a particular partition key was specified.
* Input to a range-scan request
The shard id. This is optional allow for support for server-side hashing and proxying in the future.
The start of the range, inclusive
The end of the range, exclusive
* The response to a range-scan request.
A portion of the records found within the specified range
Creates a new client session. Sessions are kept alive by regularly sending heartbeats via the KeepAlive rpc.
Sends a heartbeat to prevent the session from timing out.
(message has no fields)
Closes a session and removes all ephemeral values associated with it.
(message has no fields)
* Input to a delete range request. Key ranges assume a UTF-8 byte sort order.
Used in:
The start of the range, inclusive
The end of the range, exclusive
* The response for a delete range request.
Used in:
Includes the error or OK
* A delete request. Deletes the specified key.
Used in:
The key
An optional expected version_id. The delete will fail if the server's current version_id does not match
* The response to a delete request or an item in a response to the delete range request.
Used in:
Includes the error or OK
* A get request. Gets the stat and optionally the value for the specified key.
Used in:
The key
Specifies whether the response should include the value
* The response to a get request.
Used in:
,Includes the error or OK
The version of the record
The value, if it was requested and there was no error
In case of non-exact queries (eg. floor, ceiling) the found key will be returned in the GetResponse.
* Represents a range of hash values [min, max)
Used in:
The minimum inclusive hash that the shard can contain
The maximum inclusive hash that the shard can contain
* The type of key comparison to apply in a get() request
Used in:
The stored key must be equal to the requested key
Search for a key that is the highest key that is <= to the requested key
Search for a key that is the lowest key that is >= to the requested key
Search for a key that is the highest key that is < to the requested key
Search for a key that is the lowest key that is > to the requested key
* The shards assignments for a given namespace
Used in:
All assignments in the response stream will contain all the assignments to bring the client up to date. For example, if a shard is split, the stream will return a single response containing all the new shard assignments as opposed to multiple stream responses, each containing a single shard assignment.
Indicates the mechanism by which the keys are assigned to the individual shards.
Used in:
Used in:
* A put request. Persists the specified key and value
Used in:
The key
The value
An optional expected version_id. The put will fail if the server's current version_id does not match
Optional. Associate the new record with the session (i.e. ephemeral record). When the session expires or is explicitly closed, the record will be automatically removed
Client identifier used to track the client that last modified an ephemeral record.
If a partition key is present, it supersedes the regular record key in determining the routing of a record to a particular shard. It is passed to the server because it needs to be persisted as part of the record. We would need the partition_key if we're going to do a split of the shards.
If one or more sequence key are specified. The key will get added suffixes based on adding the delta to the current highest key with the same prefix
* The response to a put request.
Used in:
Includes the error or OK
The version if the put was successful
If the key was generated by Oxia, it will be returned as part of the response
Used in:
,* The assignment of a shard to a server.
Used in:
The shard id
The shard leader, e.g. `host:port`
There could be multiple ways to describe the boundaries of a shard
* The response to a shard assignments request.
Used as request type in: replication.OxiaCoordination.PushShardAssignments
Used as response type in: OxiaClient.GetShardAssignments
Used in:
* Represents all the possible status.
Used in:
, , ,Operation was successful
The key was not found
The existing version does not match the expected version
The session that the put request referred to is not alive
* Version contains info about the state of a record.
Used in:
,The version identifier of the record
The number of modifications made to the record since it was created
The creation timestamp of the first version of the record
The modified timestamp of the current version of the record
Identifier of the session if the record is ephemeral
* A batch write request. Applies the batches of requests. Requests are processed in positional order within batches and the batch types are processed in the following order: puts, deletes, delete_ranges.
Used as request type in: OxiaClient.Write, OxiaClient.WriteStream
Used as field type in:
The shard id. This is optional allow for support for server-side hashing and proxying in the future.
The put requests
The delete requests
The delete range requests
* The response to a batch write request. Responses of each type respect the order of the original requests.
Used as response type in: OxiaClient.Write, OxiaClient.WriteStream
The put responses
The delete responses
The delete range responses