Just add it to your Cargo.toml
, like so:
falkordb = { version = "0.1" }
Docker:
docker run --rm -p 6379:6379 falkordb/falkordb
use falkordb::{FalkorClientBuilder, FalkorConnectionInfo};
// Connect to FalkorDB
let connection_info: FalkorConnectionInfo = "falkor://127.0.0.1:6379".try_into()
.expect("Invalid connection info");
let client = FalkorClientBuilder::new()
.with_connection_info(connection_info)
.build().expect("Failed to build client");
// Select the social graph
let mut graph = client.select_graph("social");
// Create 100 nodes and return a handful
let nodes = graph.query("UNWIND range(0, 100) AS i CREATE (n { v:1 }) RETURN n LIMIT 10")
.with_timeout(5000).execute().expect("Failed executing query");
// Can also be collected, like any other iterator
while let Some(node) = nodes.data.next() {
println ! ("{:?}", node);
}
This client supports nonblocking API using the tokio
runtime.
It can be enabled like so:
falkordb = { version = "0.1", features = ["tokio"] }
Currently, this API requires running within a
multi_threaded tokio scheduler
, and
does not support the current_thread
one, but this will probably be supported in the future.
The API uses an almost identical API, but the various functions need to be awaited:
use falkordb::{FalkorClientBuilder, FalkorConnectionInfo};
// Connect to FalkorDB
let connection_info: FalkorConnectionInfo = "falkor://127.0.0.1:6379".try_into()
.expect("Invalid connection info");
let client = FalkorClientBuilder::new_async()
.with_connection_info(connection_info)
.build().await.expect("Failed to build client");
// Select the social graph
let mut graph = client.select_graph("social");
// Create 100 nodes and return a handful
let nodes = graph.query("UNWIND range(0, 100) AS i CREATE (n { v:1 }) RETURN n LIMIT 10")
.with_timeout(5000).execute().await.expect("Failed executing query");
// Graph operations are asynchronous, but parsing is still concurrent:
while let Some(node) = nodes.data.next() {
println ! ("{:?}", node);
}
Note that thread safety is still up to the user to ensure, I.e. an AsyncGraph
cannot simply be sent to a task spawned
by tokio and expected to be used later,
it must be wrapped in an Arc<Mutex<_>> or something similar.
This client is currently built upon the redis
crate, and therefore supports TLS
using
its implementation, which uses either rustls
or
native_tls
.
This is not enabled by default, and the user ust opt-in by enabling the respective features: "rustls"
/"native-tls"
(
when using tokio: "tokio-rustls"
/"tokio-native-tls"
).
For Rustls:
falkordb = { version = "0.1", features = ["rustls"] }
falkordb = { version = "0.1", features = ["tokio-rustls"] }
For Native TLS:
falkordb = { version = "0.1", features = ["native-tls"] }
falkordb = { version = "0.1", features = ["tokio-native-tls"] }
This crate fully supports instrumentation using the tracing
crate, to use
it, simply, enable the tracing
feature:
falkordb = { version = "0.1", features = ["tracing"] }
Note that different functions use different filtration levels, to avoid spamming your tests, be sure to enable the correct level as you desire it.