Support SqlStreamStore

[bartelink]

SqlStreamStore is a SQL-focused library addressing many of the concerns Equinox does, with support for SQL Server and Postgres. Given the common EventStore (and DDD-CQRS-ES slack!)-influenced designs, there's a good chance there'd be minimal work required on either side to add an Equinox.SqlStreamStore adapter

Doing this work would:

• improve the breed wrt generalizing the store interfaces in Equinox (SqlStreamStore has a wealth of experience behind it)
• provide an avenue for folks looking for a hosted solutions without having to concern themselves with request charges (likely giving up some perf, but the CLI benchmark facility will tell all)

Initial implementation should probably take a dependency on a Sql LocalDb, but there's an obvious need for it to work well with Azure SQL (the CLI would likely manage the provisioning etc. see #59)

[NatElkins]

@bartelink Has there been any consideration of using https://github.com/JasperFx/Marten as a backing store?

[bartelink]

Hey Nat, good question. While I'm aware of Marten from the blog and a podcast or two, I'm unfamiliar with the details of what Marten does wrt event sourcing and/or whether it would mesh well. Wild guess says it brings a programming model and an opinion to the table to a greater degree than SSS does.

Clearly Postgres is a very suitable target though. (Also is it Marten Postgres-only? SQL Server / Azure SQL would be an important DB to support)

I guess the key to answering your question would be to ask whether Marten offers an easier path to integration as a first class Equinox adapter; I'd be delighted to hear anyone's insight wrt that. (other considerations are having low dependencies, and the potential to integrate detailed metrics and logging)

eta: This does not necessarily need to be an either/or - if it fits, there is no problem in having both in the end. The above is simply the high level decision process I'd be using to decide where to start wrt supporting SQL Server and Postgres (with a key element being standing on the shoulders of giants in terms of finding a well-proven set of tests, SQL Schema and community)

[bartelink]

Quick scan says:
+: excellent docs, it seems the ES APIs would facilitate an easy initial implementation
-: there's a heck of a lot to Marten's codebase as it's doing all those things - that leads to lots of dependencies and code to traverse which would not be relevant for Equinox
-: not low on dependencies ?
0: the projections stuff in the cosmos branch and how it will integrate into https://github.com/jet/equinox/wiki/Cosmos-Storage-Model will likely be applicable to Postgres and SQL Server too so that aspect is not beneficial)

Marten is clearly a very capable system with good docs, community and tests but my sense/bias that it's already trying to do a lot of things (and that this fact would make an integration problematic) isn't reduced by my scan

[NatElkins]

@bartelink Thanks for the write up. I don't necessarily think it's a good idea either, I just know that there's a big overlap in features and was wondering if it had been looked at as a backing store. Thanks for taking the time to dig in a bit.

[bartelink]

.@NatElkins it seems that CosmoStore is gaining support for Marten https://github.com/Dzoukr/CosmoStore/tree/master/src/CosmoStore.Marten
(I got a few hours into a spike on SSS after the above discussion; and my bias remains that this is going to be the best fit, should I end up in a space where I have spare capacity to attack this need)

This issue remains very much open should anyone wish to contribute; I believe the caching, snapshotting, benchmarking support in here and potential to cleanly add cold storage strategies remain a very good fit for using a SQL based store with. (By the same token, if anyone is interested, it it's not a problem to have support for Marten and SSS in Equinox)

[bartelink]

Removing up-for-grabs as an implementation is underway

[bartelink]

See #168