innoave/rincon now has a Chat Room on Gitter

@haraldmaida has just created a chat room. You can visit it here: https://gitter.im/innoave/rincon.

This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.

Happy chatting.

PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

innoave/arangodb-rust-driver now has a Chat Room on Gitter

@haraldmaida has just created a chat room. You can visit it here: https://gitter.im/innoave/arangodb-rust-driver.

This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.

Happy chatting.

PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

Openssl 0.9 is breaking on a growing number of Linux systems see this issue. hyper-tls 0.3 is the first to depend on native-tls 0.2, which is the first native-tls version to drop openssl 0.9. Hyper-tls, as far as I can tell, needs hyper 0.12 to work.

We currently use hyper 0.11, and hyper 0.12 is quite an upgrade with a few breaking changes (release notes).

An upgrade also breaks the hyper-timeout dependency, which as far as I can tell, needs hyper 0.11 to work (I've filed another issue here). An idea would be to drop hyper-timeout in favor of using tokio_core::reactor to timeout from outside hyper inside of impl Execute for JsonHttpConnection -> execute() inside rincon_connector/src/http/mod.rs, following advice on hyper's issue "Request timeouts". It also looks like Hyper is working on client timeouts at this issue (last update April 2019).

Another annoying change is that the typed headers (like ContentType::json(), most stuff from hyper::header) were removed, though they might be available in the headers crate, which is related to hyper and has good usage.

The biggest decision is what to do about timeouts, and I don't care for the idea of waiting for other projects to fix issues.

So basically, cargo test doesn't work on a fresh Rincon clone on my Manjaro Linux machine right now, and this is an explanation of the rabbit hole I went down to find out why. Bit of a mess, but there you go. High hopes!

Any plans on adding support for this: https://www.arangodb.com/2019/08/rc7-of-arangodb-3-5-streaming-transactions-api/

Also, definitely keep up the good work here! I am planning on cutting a system over to ArangoDB which has previously been based on MongoDB. It would be excellent to see support for this stuff as well as async support based on the new futures & async/await features landing in Rust.

Also, I built the Wither ODM a while back, which is great, but the MongoDB team has left the underlying driver in a pretty stagnant state. Do you think there is value in building a data modelling ODM-like system for Arango as well?

Feel free to close as this is just whining about the API, but I think the unwrap methods should be renamed on the Cursor types, and perhaps elsewhere. See for example

https://docs.rs/rincon_session/0.1.0/rincon_session/client/struct.Cursor.html#method.unwrap

The issue is that unwrap on Result and Option may cause the thread to panic, so readers of code may have an aversion to any functions with this name because they may mistake it for a potential "panic on error".

A better name would be into_inner, such as used by https://doc.rust-lang.org/std/io/struct.Cursor.html#method.into_inner

The asynchronous session API of the rincon_session_async crate should provide similar functions as the rincon_session crate but return its result wrapped inside a Future.

Implement more methods of the ArangoDB's REST API marked for milestone 3 (M.3).

The rincon_client crate does not implement all methods of ArangoDB's REST API. The current status is documented in docs/arangodb_rest_api_methods.md. Methods that are planned to be implemented are marked with a milestone.