use latest protos from EventStore v21.6.0+ #43
Conversation
|
running the test suite against eventstore 21.2.0 fails a bunch of persistent subscription test cases there's a chance I'm just treating these protos wrong but if these new protos are not backwards compatible then we're kinda borked and will have to hold on to potentially all versions of all protos 😬 |
|
actually it looks like the protos are backwards compatible because of the way the indexing of the fields works |
| event_store.client.shared.StreamIdentifier stream_identifier = 1; | ||
| oneof stream_option { | ||
| event_store.client.StreamIdentifier stream_identifier = 1; | ||
| event_store.client.Empty all = 5; |
There was a problem hiding this comment.
example of how this works with backwards compatibility: the fields are indexed as their locations in the encoded proto messages, so eventstore can support passing new information to old versions of eventstoredb because the old versions don't know these indices and will fuzz off that data
kinda cool
| StreamOptions stream = 4; | ||
| AllOptions all = 5; | ||
| } | ||
| event_store.client.StreamIdentifier stream_identifier = 1 [deprecated=true]; |
There was a problem hiding this comment.
the [dreprecated=true] symbol has me worried that eventually we'll need to either support multiple major versions of spear or do some smart on-the-fly protobuf-module selection magic 😬
|
note that many of the files in this PR are either auto-generated or copied from the EventStore repository better hygiene around this is desirable. this might actually be a valid use of submodules 🤦 |
connects #41
sets the stage for using persistent subscriptions to the all stream and a new batch_append function