Crate eventstore_tcp

Tokio-based EventStore client library in it's early stages. Currently the most interesting API is the tokio_service::service::Service implemented by client::Client, which allows sending values of Package to get back a Future of a response Package. Package is the name for a frame in the protocol. See it's documentation for more information.

You can build values of Package using builder::Builder and it's functions. Actual payloads are described as Message enum.

The protocol is multiplexed so you can have multiple (hard limit is 128 currently) calls going at any point in time. Current implementation is based on tokio_proto::multiplex, at the moment using a custom fork. It does not yet support tokio_proto::streaming::multiplex which is needed to support subscriptions.

Panics

There should not be any panicing now that adapted and raw are separate.

Simplest example

Example of writing to the database and simple handling of the response.

extern crate futures;
extern crate tokio_core;
extern crate tokio_proto;
extern crate tokio_service;
extern crate eventstore_tcp;

use std::net::SocketAddr;
use futures::Future;
use tokio_core::reactor::Core;
use tokio_service::Service;

use eventstore_tcp::{EventStoreClient, Builder, AdaptedMessage, StreamVersion, ContentType};

fn main() {
    let addr = "127.0.0.1:1113".parse::<SocketAddr>().unwrap();
    let mut core = Core::new().unwrap();

    // connecting the client returns a future for an EventStoreClient
    // which implements tokio_service::Service
    let client = EventStoreClient::connect(&addr, &core.handle());

    let value = client.and_then(|client| {
        // once the connection is made and EventStoreClient (`client`)
        // is created, send a WriteEvents request:
        client.call(Builder::write_events()
            .stream_id("my_stream-1")
            .expected_version(StreamVersion::from(42))
            .new_event()
                .event_type("meaning_of_life")
                .data("{ 'meaning': 42 }".as_bytes())
                .data_content_type(ContentType::Json)
            .done()
            .build_package(None, None))

        // call returns a future representing the response
    }).and_then(|resp| {
        // By default, `resp` is a `Package` that contains the raw protobuf defined message
        // (`RawMessage`). It is possible to refine it into AdaptedMessage which can fail:
        match resp.message.try_adapt().unwrap() {
            AdaptedMessage::WriteEventsCompleted(Ok(_)) =>
                println!("Event was written successfully"),
            AdaptedMessage::WriteEventsCompleted(Err(fail)) =>
                println!("Event writing failed: {:?}", fail),
            unexpected => println!("Unexpected response: {:#?}", unexpected),
        };

        Ok(())
    });

    core.run(value).unwrap();
}

More examples can be found in the aspiring command line tool under examples/testclient.

Reexports

pub use raw::RawMessage;

pub use raw::client_messages::WriteEvents;

pub use raw::client_messages::ResolvedIndexedEvent;

pub use raw::client_messages::EventRecord;

pub use raw::client_messages::ReadAllEvents;

pub use raw::client_messages::mod_NotHandled::NotHandledReason;

pub use raw::client_messages::mod_NotHandled::MasterInfo;

pub use adapted::AdaptedMessage;

pub use package::Package;

pub use builder::Builder;

Modules

adapted	Adapted or refined types providing a much more oxidized API for handling the messages in the protocol.
builder	Builders to help building requests.
codec	codec module contains the Package (frame) decoding and an tokio_core::io::Codec implementation.
package	Frame and MessageContainer
raw	Raw module contains the enumeration RawMessage and raw decoding and encoding functionality. There should not be need to handle RawMessage values directly but if there is ever a bug, using the raw messages should still work.

Structs

EventStoreClient	tokio_service::Service implementation of the client.
StreamVersion	StreamVersion represents the valid values for a stream version which is the same as the event number of the latest event. As such, values are non-negative integers up to i32::max_value. Negative values of i32 have special meaning in the protocol, and are restricted from being used with this type.
UsernamePassword	Username and password authentication token embedded in requests as there is no concept of session in the TCP protocol, every request must be authenticated.

Enums

ContentType	Content type of the event data or metadata.
EventNumber	EventNumber is similar to StreamVersion and ExpectedVersion but is used when specifying a position to read from in the stream. Allows specifying the first or last (when reading backwards) event in addition to exact event number.
ExpectedVersion	ExpectedVersion represents the different modes of optimistic locking when writing to a stream using WriteEventsBuilder.
LogPosition	Global unique position in the EventStore, used when reading all events. Range -1..i64::max_value()
ReadDirection	The direction in which events are read.