mirror of
https://github.com/scylladb/scylladb.git
synced 2026-06-06 06:53:12 +00:00
6028588148
The patch introduces two new features to aid with negotiating protocol extensions for the CQL protocol: - `cql_protocol_extensions` enum, which holds all supported extensions for the CQL protocol (currently contains only `LWT_ADD_METADATA_MARK` extension, which will be mentioned below). - An additional mechainsm of negotiating cql protocol extensions to be used in a client connection between a scylla server and a client driver. These extensions are propagated in SUPPORTED message sent from the server side with "SCYLLA_" prefix and received back as a response from the client driver in order to determine intersection between the cql extensions that are both supported by the server and acknowledged by a client driver. This intersection of features is later determined to be a working set of cql protocol extensions in use for the current `client_state`, which is associated with a particular client connection. This way we can easily settle on the used extensions set on both sides of the connection. Currently there is only one value: `LWT_ADD_METADATA_MARK`, which regulates whether to set a designated bit in prepared statement metadata indicating if the statement at hand is an lwt statement or not (actual implementation for the feature will be in a later patch). Each extension can also propagate some custom parameters to the corresponding key. CQL protocol specification allows to send a list of values with each key in the SUPPORTED message, we use that to pass parameters to extensions as `PARAM=VALUE` strings. In case of `LWT_ADD_METADATA_MARK` it's `SCYLLA_LWT_OPTIMIZATION_META_BIT_MASK` which designates the bitmask for LWT flag in prepared statement metadata in order to be used for lookup in a client library. The associated bits of code in `cql3::prepared_metadata` are adjusted to accomodate the feature. The value for the flag is chosen on purpose to be the last bit in the flags bitset since we don't want to possibly clash with C* implementation in case they add more possible flag values to prepared metadata (though there is an issue regarding that: https://issues.apache.org/jira/browse/CASSANDRA-15746). If it's fixed in upstream Cassandra, then we could synchronize the value for the flag with them. Also extend the underlying type of `flag` enum in `cql3::prepared_metadata` to be `uint32_t` instead of `uint8_t` because in either case flags mask is serialized as 32-bit integer. In theory, shard-awareness extension support also should be reworked in terms of provided minimal infrastructure, but for the sake of simplicity, this is left to be done in a follow-up some time later. This solution eliminates the need to assume that all the client drivers follow the CQL spec carefully because scylla-specific features and protocol extensions could be enabled only in case both server and client driver negotiate the supported feature set. Tests: unit(dev, debug) Signed-off-by: Pavel Solodovnikov <pa.solodovnikov@scylladb.com>
Scylla developer documentation
This folder (and its subfolders) contain developer-oriented documentation concerning the Scylla codebase. We also have a wiki, which contains additional developer-oriented documentation. There is currently no clear definition of what goes where, so when looking for something be sure to check both.
Seastar documentation can be found here.
User documentation can be found on docs.scylladb.com
For information on how to build Scylla and how to contribute visit HACKING.md and CONTRIBUTING.md.