alexpikalov / cdrs Goto Github PK

End session when its instance dropped. Use implementation of std::ops::Drop trait.

PS thanks DevNullAsAService for the feedback

I tried with tls and I started with a wrong certificate and so it was supposed to return error instead it was panicking.

   thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Failure(MidHandshakeSslStream { stream: SslStream { stream: TcpStream { addr: V4(xxx:64067), peer: V4(xxxx:9042), fd: 3 }, ssl: Ssl { state: "error", verify_result: X509VerifyError { code: 19, error: "self signed certificate in certificate chain" } } }, error: Ssl(ErrorStack([Error { code: 336134278, library: "SSL routines", function: "ssl3_get_server_certificate", reason: "certificate verify failed" }])) })', /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/libcore/result.rs:837
stack backtrace:
       1:        0x10f8e0dda - std::sys::imp::backtrace::tracing::imp::write::hd8952e96bd20f4b7
       2:        0x10f8e255f - std::panicking::default_hook::{{closure}}::hfd6ba86ea4dd6ba9
       3:        0x10f8e2207 - std::panicking::default_hook::h44ade8c78c995294
       4:        0x10f8e2a26 - std::panicking::rust_panic_with_hook::h3e771863e3ed8403
       5:        0x10f8e2874 - std::panicking::begin_panic::h0af46715c5e7593e
       6:        0x10f8e27e2 - std::panicking::begin_panic_fmt::h9509a584fa230ae8
       7:        0x10f8e2747 - rust_begin_unwind
       8:        0x10f9051f0 - core::panicking::panic_fmt::h5c28b8150c75bd71
       9:        0x10f879ee0 - core::result::unwrap_failed::h3e2777ab86f331c6
      10:        0x10f86e86c - <core::result::Result<T, E>>::unwrap::h8624c0fc54826597
      11:        0x10f8a645e - cdrs::transport_ssl::Transport::new::{{closure}}::h2f0231b2a03a7ed4
      12:        0x10f86df87 - <core::result::Result<T, E>>::map::ha45322ee1b6c6507
      13:        0x10f8a630d - cdrs::transport_ssl::Transport::new::h517c6ceb7fe0f49d
      14:        0x10f8598aa - cdrs_dart::main::h7080965054f13a02
      15:        0x10f8e389a - __rust_maybe_catch_panic
      16:        0x10f8e2dc6 - std::rt::lang_start::hefd96b70277e8a4a
      17:        0x10f85a5c9 - main

the code which was used
https://gist.github.com/harrydevnull/c807dcea1f9b552cc21fa9df0eaccc27

In looking into the possibility of creating a cdrs backend for diesel, I realized that it would be much easier to embed cdrs in other things if it implements eq.

In current implementation query method of Session takes a bunch of arguments which is not convenient for consumers. We'd like to refactor it to make it taking a single argument of type Query.

Possible usage:

let query = Query::new("SELECT * from users;"); // query with default parameters
let query_with_params = query
    .with_consistency(Consistency::One)  // rewrite default consistency
    .with_page_size(100); // rewrite default page size

let res_frame: Frame = try!(session.query(query_with_params));

Based on discussion on reddit.

I have been trying to get the prepared statement to work but it is not .

CQL query

Insert into user_keyspace.users (user_name ,password,gender,session_token, state,birth_year) values (? , ? , ?, ?, ?, ?)

Error

CDRSError { error_code: 8704, message: CString { string: "there were 6 markers(?) in CQL but 0 bound variables" }

I have pushed the code to my branch
https://github.com/harrydevnull/cdrs/tree/feature/more-integ-test

could you please take a look?

We need to rid of as many unwraps as possible to avoid panic.

As we're going to actively use cargo fmt to keep code consistent, I think, it makes sense to define the rules in .rustfmt.toml (which we have also create).

At the moment IP address is configurable only. We need to provide an ability to configure server port as well.

As mentioned on Reddit, I'm planning to add support for migrations for Cassandra in https://github.com/Keats/dbmigrate

Would it be possible to add a method to cdrs to get a connection from a string like cassandra://username:password@host:port/keyspace?

Create options as a method of CDRS instance to retrieve available options before establishing new Session.

This section misleads some developers who start using CDRS. We need to make it more similar to a code from examples

Improve performance by reducing unnecessary .clone().

E.g.:

impl Frame {
    pub fn get_body(&self) -> ResponseBody {
        return ResponseBody::from(self.body.clone(), &self.opcode);
    }

double allocation

We need to create an examples folder that would contain examples of different use cases.

Preliminary following features are considered for implementation:

• tls - should provide tls transport for encrypted server-client communicatoin

TBC

I had been trying to revamp api using cassandra name as option but i was not able to get it to working.
it is because of the move

error[E0505]: cannot move out of `self` because it is borrowed
   --> src/client.rs:102:50
    |
94  |             let cass_name =  self.authenticator.get_cassandra_name();
    |                              ------------------ borrow of `self.authenticator` occurs here
...
102 |                         return Ok(Session::start(self));
    |                                                  ^^^^ move out of `self` occurs here

error: aborting due to previous error

error: Could not compile `cars`.

i have uploaded the code in my fork

harrydevnull#6

would you know what to do to get around it ?

We're going to have a list of impl Into<Value> for X implementations for all of Rust primitive types and their vectors.

As an example, please refer to this code.

There is a no way to easily map CDRS Result Frame into Rust structures and columns into types. At the moment CDRS consumer should obtain a column value, find its type from metadata, and then decode bytes into Rust type basing on related type found in metadata.

We need to find a way to provide such functionality as a part of CDRS driver.

i was trying to connect cassandra 2.2.4 on our network; but unfortunately rust panicked

source code

below is the stacktrace which I got

RUST_BACKTRACE=1 ./target/debug/cassandraaccess Hello, world! thread 'main' panicked at 'Unexpected Cassandra version [0]', /Users/hachandr/.cargo/registry/src/github.com-1ecc6299db9ec823/cdrs-0.2.0/src/frame/mod.rs:117 stack backtrace: 1: 0x10e414d28 - std::sys::backtrace::tracing::imp::write::h6f1d53a70916b90d 2: 0x10e41730f - std::panicking::default_hook::{{closure}}::h137e876f7d3b5850 3: 0x10e416095 - std::panicking::default_hook::h0ac3811ec7cee78c 4: 0x10e4165e6 - std::panicking::rust_panic_with_hook::hc303199e04562edf 5: 0x10e416484 - std::panicking::begin_panic::h6ed03353807cf54d 6: 0x10e4163a2 - std::panicking::begin_panic_fmt::hc321cece241bb2f5 7: 0x10e3fca1f - <cdrs::frame::Version as core::convert::From<collections::vec::Vec<u8>>>::from::h32cd9558c9a9ab7d 8: 0x10e3faedb - cdrs::frame::parser::parse_frame::hd0b56c419b3c4827 9: 0x10e3c76c1 - <cdrs::client::CDRS<T>>::start::hb87ef6d337d3d9e4 10: 0x10e3cff4a - cassandraaccess::main::haeac6d31fbfd637f 11: 0x10e4178ca - __rust_maybe_catch_panic 12: 0x10e415bd6 - std::rt::lang_start::h538f8960e7644c80 13: 0x10e3d0289 - main

In current implementation result frame body parser does NOT handle a case when query was send with warning flag, so it does not expect to have a list of warnings in a head of frame's body.

We need to update a parser and related frame body structures:

• BodyResResultRows
• BodyResResultSetKeyspace
• BodyResResultPrepared
• BodyResResultSchemaChange

NB take into account a case when both tracing and warning flags are set. In this case warnings go right after tracing id.

https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v4.spec#L132

Found in #96

Description: when body contains null or not-set values .get_body() runs out of memory.

Root cause: issue with parsing negative integers

It's a separate issue for load balancing functionality

harrydevnull in #31:

Similarly which node does the client connect to and what to specify what kind of load balancing policy have to be used.

details : https://teddyma.gitbooks.io/learncassandra/content/client/which_node_to_connect.html

Reported in #61

When --all-features was used, the ssl transport
was provided via the transport_ssl module.
However, the examples were not prepared for this,
and cargo test --all-features would fail.

As both transports are mutually exclusive, it
seems reasonable to just use the same module name
and make life easier for clients.

• fix existing examples
• add examples which would use ssl

Add a separate script which would run tests with ssl feature. Similar to cargo test --features ssl.

In current implementation AsRust trait declares that as_rust method should return Option value.

As an error may occur during transformation of a frame into "Rust-structs" it would be better to return some Result instead.

For that purposes we need to introduce new type of CDRS error that wrap up errors that may occur during the transformation .

In scope of conditional compilation (#29), move compression functionality into a Rust feature scope

right now the driver takes only a single node address as the input; in reality we should accept an array of hosts.

    let addr = "127.0.0.1:9042";
    let tcp_transport = TransportTcp::new(addr).unwrap();

to be replaced with

    let nodes = "10.10.10.10:9042,10.10.10.11:9042,10.10.10.12:9042,10.10.10.13:9042"
    let tcp_transport = TransportTcp::new(nodes).unwrap();

At the moment a process of conversion from Cassandra list to Rust Vec<T> look a bit complicated comparing to conversion of primitive type. A developer has to perform it in two steps: 1.) convert bytes into CDRS List and then convert List into Rust Vec<T>. The same situation for Cassandra set and map.

The goal is to eliminate this intermediate step and to enable a direct conversion from list to Vec<T>

I know we just have got the cluster manager api up. the nodes can be brought up online or node can die. we can get those information via the server events. using the server event api we should dynamically add/remove the nodes from manager pool.

This is a super-task (in meaning it contains a list of subtasks).

We need to add tests to each frame in frame module to make a process of parsing and serialization more mature.

• events
• frame_auth_challenge
• frame_auth_response
• frame_auth_success
• frame_authenticate
• frame_batch
• frame_error
• frame_event
• frame_execute
• frame_options
• frame_prepare
• frame_query
• frame_ready
• frame_register
• frame_response
• frame_result
• frame_startup
• frame_supported
• mod
• parser

It's good to refactor PasswordAuthenicator::new to make it able to receive parameters as &str instead of String

In accordance to v4 protocol we have to support Batch Query Frame, then we need to provide a suitable API for consumers.

it seems after SSL stuff is not compiling at all

In current implementation result frame body parser does NOT handle a case when query was send with tracing flag, so it does not expect to have tracing id in a head of frame's body.

We need to update a parser and related frame body structures:

• BodyResResultRows

• BodyResResultSetKeyspace

• BodyResResultPrepared

• BodyResResultSchemaChange

https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v4.spec#L115

when we run cargo clippy it will spill out a lot of warnings. we might want to tackle that as we code.
cargo clippy
cargo fmt as well.

As of now it shows that coverage is 100% which is not true.

It seems to be related to huonw/travis-cargo#43

while trying to execute the read_table_into_struct.rs the rust thread was panicking.

the rootcause of the issue is
emp_id is an int on cassandra table and we are trying to deserialize to i64
conversion from varint to i64 is seamless.

It would be good to provide a table for Rust and Cassandra corresponded types.

Create more e2e tests based on all example

cassandra client has to provide connection pooling options.For each Session, there should be one connection pool per connected host
details : http://docs.datastax.com/en/developer/java-driver/3.1/manual/pooling/

Similarly which node does the client connect to and what to specify what kind of load balancing policy have to be used.

details : https://teddyma.gitbooks.io/learncassandra/content/client/which_node_to_connect.html

In accordance to v4 protocol we need to support Register and Event frames, and then provide an API for handling events.

At the moment it is cumbersome to bind values to INSERT, UPDATE queries.

I suggest something similar to PostgreSQL crate: https://github.com/sfackler/rust-postgres.

    conn.execute("INSERT INTO person (name, data) VALUES ($1, $2)",
                 &[&me.name, &me.data]).unwrap();

A lot of projects in Rust ecosystem use dual-licensing allowing downstream user to choose between MIT or Apache license which simplifies library use both for projects under GPLv2 (Apache License v2 is incompatible with it, so MIT is good choise) and others who wouldn't be forced to keep a copy of your full license in NOTICE file and could just put attribution there.

CDRS requires an Authenticator to be passed during initialisation. That is not suitable for those who work with Cassandra instance that does not need any authorisation. At current moment in order to initialise CDRS developers need to create their own authenticator and implement Authenticator trait for it.

So, I think we may provide such empty authenticator specially for such cases.

I propose to create AuthenticatorNone which returns empty auth token and empty Cassandra class name.

Diesel is an increasingly popular native rust ORM, and I don't think anything on its design would preclude using most of its features with a nosql engine like cassandra.
Filing this as a placeholder, and to gauge interest. I hope to be able to work on this soon, and would love collaborators.

http://diesel.rs

Since it's possible to configure a server to communicate with clients via encrypted connection we need to support this option as well.

Basing on discussion #109 and thread on Reddit we'd like to have Result<Option<_>> instead of current Option<Result<_>>.

From reddit

Looking good! One small suggestion. Unless you have a good reason to do otherwise, it might save you some trouble in the future to avoid re-exporting types from other crates. The reason why this is important is because multiple versions of, say, snap could get compiled into a single binary, and you might wind up with type conflicts. I could imagine some particularly nasty From impls going awry with try!/? in this particular case.
There are two ways to work around re-exporting the type:
Wrap the type and implement Error on it. Don't expose any internal types. This is annoying because you need to do all of the various error impls.
Use Snappy(String) instead of Snappy(snap::Error). This prevents introspection into the underlying error though.

Thank you this crate !

I have a suggestion regarding connection pool, de facto for pools in Rust is r2d2 https://github.com/sfackler/r2d2 have you considered it ?