Writing to a stream
You can use the client API to write one or more events to a stream atomically. You do this by appending the events to the stream in one operation, or by starting a transaction on the stream, writing events in one or more operations in that transaction, and then committing the transaction.
You can make an optimistic concurrency check during the write by specifying the version at which you expect the stream to be. Identical write operations are idempotent if the optimistic concurrency check is not disabled. You can find more information on optimistic concurrency and idempotence here.
Appending to a stream in a single write
Task<WriteResult> AppendToStreamAsync(string stream, long expectedVersion, IEnumerable<EventData> events)
Task<WriteResult> AppendToStreamAsync(string stream, long expectedVersion, params EventData events)
Using a transaction to append to a stream across multiple writes
Task<EventStoreTransaction> StartTransactionAsync(string stream, long expectedVersion)
EventStoreTransaction ContinueTransaction(long transactionId)
Task WriteAsync(IEnumerable<EventData> events)
Task WriteAsync(params EventData events)
The writing methods all use a type named
EventData to represent an event to be stored. Instances of
EventData are immutable.
Event Store does not have any built-in serialisation, so the body and metadata for each event are represented in
EventData as a
The members on
||A unique identifier representing this event. Event Store uses this for idempotency if you write the same event twice you should use the same identifier both times.|
||The name of the event type. You can use this for pattern matching in projections, so should be a "friendly" name rather than a CLR type name, for example.|
||If the data and metadata fields are serialized as JSON, you should set this to
||The serialized data representing the event to be stored.|
||The serialized data representing metadata about the event to be stored.|
Append to a stream in a single write
AppendToStreamAsync method writes events atomically to the end of a stream, working in an asynchronous manner.
The parameters are:
||The name of the stream to which to append.|
||The version at which you expect the stream to be in order that an optimistic concurrency check can be performed. This should either be a positive integer, or one of the constants
||The events to append. There is also an overload of each method which takes the events as a
Deleting a stream
Task<DeleteResult> DeleteStreamAsync(string stream, long expectedVersion, UserCredentials userCredentials = null);
By default when you delete a stream, Event Store soft deletes it. You can recreate the stream by appending new events to it. If you try to read a soft deleted stream you receive an error response.
You can hard delete a stream.
A hard delete is permanent and the stream is not removed during a scavenge. If you hard delete a stream, you cannot recreate the stream.
Task<DeleteResult> DeleteStreamAsync(string stream, long expectedVersion, bool hardDelete, UserCredentials userCredentials = null);