Migration from .NET Client API 2.x to 3.x

EventStoreDB
1

Hello,
currently i’m evaluate the migration of my application from the EventStore Client API 2.x to 3.x.
The following questions came up:
1.) SubscribeToAllFrom() vs SubscribeToStreamFrom("$all", …)
What is the real difference between the two Catch-Up subscriptions other then the first is using “Position” as lastCheckpoint and the second is using an integer?
An integer is easier to store in the local storage :wink:
2.) SubscribeToXYZFrom() is not async
Any reason why the two Catch-Up Subscriptions are not async as any other method on the client API? (I dont need async here, just want to know)
3.) Catch-Up subscription should always be alive
With the 2.x API i had a lot of work to have the subscription always be alive by getting connection and subscription disconnected/dropped events and calling mySubscription.Start() again.
But this was not always working. Sometimes the subscription was in inactive mode.
As far as i can see the new client api takes care of this and subscribes to the connection.Connected event and restarts the subscription. So i dont have any other work then creating the subscription.
But i want to be sure that this is the case.
4.) Regarding “$all” stream
Is the still the recommend way to get all of your own events of all streams in correct order via subscription (currently i simply ignore everything starting with $) without using projections (that are still beta)
5.) Transaction Support

Greg mentioned that the support for transaction could be removed. Currently i’m using code like this: https://github.com/EventStore/getting-started-with-event-store/blob/master/src/GetEventStoreRepository/GetEventStoreRepository.cs#L115
to write events.

What is the new recommend pattern without transactions to write more events then the write page size? (I don’t know if i’ll ever have more then 5 at once, so just want to know)

Thanks for your help.

Daniel

2

  1. $all stream does not use an integer to record position. not sure what SubscribeToStreamFrom("$all", …) would actually do, probably blow up

  2. I would stick to this or the built in projections for now. I wouldn’t bother optimizing this with stream repartitioning until you really need it. e.g. you can’t catch up because too many events are coming through the pipe

  3. if your aggregate is emitting hundreds of events on a single method call maybe you’re doing it wrong? :slight_smile:

3

inline

Hello,

currently i'm evaluate the migration of my application from the EventStore
Client API 2.x to 3.x.

The following questions came up:

1.) SubscribeToAllFrom() vs SubscribeToStreamFrom("$all", ...)

What is the real difference between the two Catch-Up subscriptions other
then the first is using "Position" as lastCheckpoint and the second is using
an integer?
An integer is easier to store in the local storage :wink:

Subscribe to All gets all events in the system (and does it in an
optimized way). You should prefer using it.

2.) SubscribeToXYZFrom() is not async

Any reason why the two Catch-Up Subscriptions are not async as any other
method on the client API? (I dont need async here, just want to know)

Because they return a subscription immediately, that subscription the
asynchronously does things.

3.) Catch-Up subscription should always be alive

With the 2.x API i had a lot of work to have the subscription always be
alive by getting connection and subscription disconnected/dropped events and
calling mySubscription.Start() again.
But this was not always working. Sometimes the subscription was in inactive
mode.

As far as i can see the new client api takes care of this and subscribes to
the connection.Connected event and restarts the subscription. So i dont have
any other work then creating the subscription.
But i want to be sure that this is the case.

It should be the case. Let us know if not.

4.) Regarding "$all" stream

Is the still the recommend way to get all of your own events of all streams
in correct order via subscription (currently i simply ignore everything
starting with $) without using projections (that are still beta)

This is a reasonable way of doing it.

5.) Transaction Support

Greg mentioned that the support for transaction could be removed. Currently
i'm using code like this:
https://github.com/EventStore/getting-started-with-event-store/blob/master/src/GetEventStoreRepository/GetEventStoreRepository.cs#L115
to write events.

Just write them with appendasync there. Are you commonly saving more
than say 100 events? Thats the only place it would make a difference.

What is the new recommend pattern without transactions to write more events
then the write page size? (I don't know if i'll ever have more then 5 at
once, so just want to know)

It being that page size can reasonably be even 1000 events the idea is
to just remove the transaction behaviour. I think however as of now
the idea is to leave it there (so many things could be simplified
internally by not having it but its there already)

4

Hello,

thanks for your answers.

@transaction: i just don’t need it as i’ve currently not more then 5 events per write. Normally only one event.

So if it help to make the code simplified -> just do it with the next major version as breaking change and provide a “migration guide” :wink:

Maybe mark them obsolete in the next release of the client, so people using it will contact you.

Daniel

5

Most of these are answered but to add some detail to this one:

1.) SubscribeToAllFrom() vs SubscribeToStreamFrom("$all", …)

What is the real difference between the two Catch-Up subscriptions other then the first is using “Position” as lastCheckpoint and the second is using an integer?
An integer is easier to store in the local storage :wink:

SubscribeToStreamFrom("$all", …) either breaks (stream not found) or should break. $all is not a real stream, it’s materialised by reading directly from the transaction file. There is no integer global sequence number across streams, so you’d be recording the wrong thing anyway.