It might not fit for your use case, but https://hexdocs.pm/icouch is the most feature complete couch library out there. I don’t use ecto at all yet so I’ve not done any investigation into couch+ecto comparisons.
Riak is maintained now, and is pretty close to a 2.9 release https://github.com/basho/riak/blob/develop-2.9/doc/Release%202.9%20Series%20-%20Overview.md although I have no idea how you’re supposed to figure that out just by reading the main repo page.
wrt CouchDB’s revision handling yup you are right, however in practice with a front end proxy in front and a sweeper view to handle conflicts I don’t really have issues in practice. It’s possible to get conflicts “inside” a cluster if couchdb can’t meet the requested quorum level (which is more of an admin problem, but …) and accepts a write with 202, and then you manage to write again to the lost node. At least, your data from both writes isn’t lost, and your application can figure out how to merge that as needed.
There’s no particular reason you couldn’t request conflict info on every GET, but personally I prefer 2 other approaches which work for me:
- have a conflicts view that triggers a background task every time it detects a conflict. I have had only a handful of these in years of running CouchDB
- design applications in a conflict-free way such that each write creates a new document, and these can be merged back via a view to only return the most appropriate data
Conflicts are a key part of CouchDB’s mesh architecture if you have multiple clusters, and in practice the issue comes up infrequently.
Given the same N revision docs, couchdb will always pick the same winner (which may not be the one you want) consistently.
Also you can embed your Elixir app “inside” CouchDB as a further supervisor. This is really cool but probably of little practical use for most people.