Date: Monday, June 24, 2019 11:57 AM
Echoing Rhys Ulerich concern that "Databases not providing the guarantees one requests are scary...", the transaction handle feature in general could give a false sense of security if the underlying OKVS doesn't support transactions. This might be addressed by using the config facility or something like it, or SRFI-167 could suggest or require bolting on a transaction facility.
Yes, I plan to make some kind of validation of config. Does it require a framework?
Very possibly. Or you could get prescriptive with config and include a feature like 'transactions-required, which would cause an error if the underlying mix-and-match library doesn't support them, or tell an adapter to use a separate and thus more expensive transaction facility.
There are applications for fast non-transaction supporting OKVSes that still maybe promise to try hard to not corrupt themselves, especially if the data they're storing isn't really linked. Particularly for spying on people; apparently this was one reason MongoDB, "Snapchat for databases", has been popular, you don't need every bit of location data about a person for all time to figure out their favorite places.
There have got to be more benign examples from the analytics world, where a fire hose of incoming data makes such trade-offs attractive.