From: Amirouche Boubekki <xxxxxx@gmail.com>
Date: Monday, June 24, 2019 11:57 AM

Le lun. 24 juin 2019 à 18:10, <xxxxxx@ancell-ent.com> a écrit :

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.

- Harold