Created
May 19, 2015 17:42
-
-
Save jen20/f061db530ae401765aeb to your computer and use it in GitHub Desktop.
A first stab at an EventStoreConnection interface for a new pure Java client
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
package com.geteventstore.client; | |
import java.util.concurrent.CompletableFuture; | |
import java.util.concurrent.Executor; | |
import java.util.function.BiConsumer; | |
import java.util.function.Consumer; | |
public interface EventStoreConnection { | |
CompletableFuture connect(); | |
void close(); | |
CompletableFuture<WriteResult> appendToStream(String streamName, int expectedVersion, EventData[] events); | |
CompletableFuture<DeleteResult> deleteStream(String streamName, int expectedVersion); | |
CompletableFuture<StreamEventsSlice> readEventsForward(String streamName, int start, int count, Boolean resolveLinks); | |
CompletableFuture<StreamEventsSlice> readEventsBackward(String streamName, int start, int count, Boolean resolveLinks); | |
CompletableFuture<SingleReadResult> readEvent(String streamName, int eventNumber, Boolean resolveLinks); | |
CompletableFuture<Subscription> subscribeToStreamLive(String streamName, | |
LinkAction linkAction, | |
BiConsumer<Subscription, ResolvedEvent> onEvent, | |
BiConsumer<Subscription, DropReason> onDrop); | |
CompletableFuture<Subscription> subscribeToStreamLive(String streamName, | |
LinkAction linkAction, | |
BiConsumer<Subscription, ResolvedEvent> onEvent, | |
BiConsumer<Subscription, DropReason> onDrop, | |
Executor executor); | |
CompletableFuture<Subscription> subscribeToAllLive(LinkAction linkAction, | |
BiConsumer<Subscription, ResolvedEvent> onEvent, | |
BiConsumer<Subscription, DropReason> onDrop); | |
CompletableFuture<Subscription> subscribeToAllLive(LinkAction linkAction, | |
BiConsumer<Subscription, ResolvedEvent> onEvent, | |
BiConsumer<Subscription, DropReason> onDrop, | |
Executor executor); | |
CompletableFuture<Subscription> subscribeToStreamFromEventNumber(String stream, | |
int eventNumber, | |
LinkAction linkAction, | |
BiConsumer<Subscription, ResolvedEvent> onEvent, | |
BiConsumer<Subscription, DropReason> onDrop, | |
Consumer<Subscription> onLiveProcessingStart); | |
CompletableFuture<Subscription> subscribeToStreamFromEventNumber(String stream, | |
int eventNumber, | |
LinkAction linkAction, | |
BiConsumer<Subscription, ResolvedEvent> onEvent, | |
BiConsumer<Subscription, DropReason> onDrop, | |
Consumer<Subscription> onLiveProcessingStart, | |
Executor executor); | |
CompletableFuture<Subscription> subscribeToAllFromPosition(Position position, | |
LinkAction linkAction, | |
BiConsumer<Subscription, ResolvedEvent> onEvent, | |
BiConsumer<Subscription, DropReason> onDrop, | |
Consumer<Subscription> onLiveProcessingStart); | |
CompletableFuture<Subscription> subscribeToAllFromPosition(Position position, | |
LinkAction linkAction, | |
BiConsumer<Subscription, ResolvedEvent> onEvent, | |
BiConsumer<Subscription, DropReason> onDrop, | |
Consumer<Subscription> onLiveProcessingStart, | |
Executor executor); | |
} |
@michael-schnell yes I'll create a repository for it and put the entire interface in there. Stand by for the repository address. Sorry for the delay, it was a holiday weekend.
To address your specific points:
- Using varargs for the
EventData
is probably a good idea - A collection version is likely also a good idea
- Constants are likely a good idea. Unlike the .NET client we're not bound by backwards compatibility constraints, so we don't need to deal with Empty stream which is an artefact of a feature which no longer exists.
- LinkAction is an enumeration of
NoAction
andResolveLinks
- if you choose to resolve them then link events will be dereferenced in the server which reduces the number of roundtrips required.
@michael-schnell the repository is here: https://github.com/jen20/EventStore.Java - let's move this discussion to the issues section of that repo.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The interface looks nice and clean.
Could you provide the source for the other objects like "EventData", "*Result", "Subscription", "ResolvedEvent", "SingleReadResult" ... ? This would help to understand the overall approach - For example: Do you pass byte arrays as data or Java objects inside the events? (For example in case of ESJ Java objects are passed and this requires some kind of serialization/deserialization mechanism to be included into the implementation.)
Findings:
Questions: