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. ]
Ok
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,
When one considers OKVS interface, both RDBMS as row stores and nstore are generic approach to store data.
nstore is more natural to sparse data where there is lot of columns and few are filled and row-store is more natural
to dense data few columns each of which has a value.
Also, implementing versioning in a row store is always ad-hoc ie. not generic.
Regarding, this topic, I think EAVT like Datomic does hits a sweet spot, in the sense that it doesn't require
as much space as nstore. But it requires extra book-keeping to respect the defined schema.
and RDBMSes bring a lot of messy power to the table, as we've been discussing WRT to validation.
Yes, when you consider validation it is easier to implement with row-store.
And there will be existing installations using RDBMSes where it would be nice to also allow Scheme to manipulate them.
There is someone who worked extensively on implementing a DSL for SQL I don't find the link right now. The result was that
it was very difficult to do because of the different syntax across DB vendors and the specifics. Yeah, they were considering
the implementation of cross-vendor SQL DSL.