From: John Cowan <xxxxxx@ccil.org>
Date: Sunday, July 07, 2019 11:15 AM
[Replacing okvs-open and -close with using/with-okvs would be] pretty restricting in how you use this SRFI, and will encourage frequent opening and closing the database, which might be expensive in some naive server based implementations, but for those will encourage connection pooling. It will also encourage making config global state, instead of using it once in a single call to okvs-open.
Good points all. What's more, one may wish to open two OKVSes and copy keys and values from one to the other.
Urk, I didn't think about that necessary use case, which would be possible with using/with-okvs, but seriously inelegant, this doesn't naturally nest like transactions do as you mentioned. I can also imagine use cases where the keys in one or more OKVS get moved into multiple new ones, sharding or resharding for example.
[ We agree on leaving -open and -close alone, and I have no strong opinions on config and home. ]
By the way, since this is now the de facto Scheme-database mailing list, I'd really be glad of a review of
While it has relevance for these OKVS based SRFIs, for conventional SQL RDBMSes I was thinking they're such a can of worms that after these SRFIs get sufficiently perfected, a mailing list and defacto working group like the ones for Schemedoc and Schemeweb might be created. I know what I personally want at the top of the stack (the korma Clojure library, and something like lobos Clojure library for DDL), but don't have a good feel for how many SRFIs are appropriate and how they should divide up the problem space. Meanwhile, I'll give RelationsCowan a look Real Soon Now (RSN).
No disrespect for the SRFI-168 N Tuple database model intended, but just as some data are unnatural for RDBMSes, some are very natural, and RDBMSes bring a lot of messy power to the table, as we've been discussing WRT to validation. And there will be existing installations using RDBMSes where it would be nice to also allow Scheme to manipulate them.
- Harold