Installation

Since it’s a native driver all you need is to install CDRS crate via Cargo and that’s it. Add it to your Cargo.toml dependencies section

Cargo.toml

and include it as an extern crate in lib.rs

lib.rs

Establishing new session and authentication flow

To start making requests you need to establish new session with Cassandra server:

Establishing new session with Cassandra Server

To establish new session you need to provide an address of Cassandra Server including port (9042 is used by server by default) and authenticator which usually requires database username and password. In case if server doesn’t require authentication you still have to provide some Authenticator (even an empty one) to get CDRS instance. Though it won’t be used in fact (most probably such workflow will be changed in one of new versions).

At the moment cars::authenticators contains a generic trait named Authenticator and one of its particular implementations PasswordAuthenticator. Password authenticator allows you to proceed with a flow described in org.apache.cassandra.auth.PasswordAuthenticator. Basing on Authenticator trait a developer is able to implement the one he needs.

NB: it’s possible that some of multistep authenticators won’t work properly. If so please create an issue and I’ll work on fix.

Apart of that, compression should be defined explicitly as well. CDRS supports all expected compressions, i.e. lz4, snappy and without any compression. Selected compression should be passed as an argument of cdrs.start method.

Once session is established successfully you can start making requests.

Making requests and mapping results

As it was described in previous section, to make requests you need to have an instance of CDRS Session. The session itself provides methods to make request. One of them is query.

It takes plenty of arguments but except of two of them each one is Option. The mandatory is query itself which is CQL string and the second one is consistency level. To get more details about each level please refer to Datastax Cassandra docs for instance.

Getting result frame.

As frames may have quite a complex inner structure (like in case of result frame) it’s not very convenient to work with them directly. To simplify it CDRS provides mappings which allow developers to map results to such Rust structures as numbers, booleans, vectors, hash-maps etc.

Let’s consider selection of messages which contain a text, an author as user defined type and list of tags. After querying you could represent a result frame as a colleciton of rows and then query values by their names.

Simple columns (those who contains values like numbers, string, booleans) could be converted into Rust values via calling val.as_rust().unwrap(). For complex columns which contain Sets, Lists, Maps or UDTs CDRS provides related helper structures: List (Cassandra’s Sets and List are the same from Rust point of view), Map and UDT.

To convert CDRS’s List into Vec<T> use .as_rust() method as in case of simple values. The same is for CDRS’s Maps. As for UDTs each value should be converted separately because generally speaking they have different types. It could by done via .get_by_name(name: &str) method which is similar to conversion of CDRS’s rows.

PS

There is a plenty of features aren’t implemented yet so any PRs, feedbacks and GH issues are more than welcome.