4 ms·
> While it's nice to say your program to store to any kind of datastore, it's much more practical to have it optimized for the kind that's best for it. I think
by alrex021 16y ago
> While it's nice to say your program to store to any kind of datastore, it's much more practical to have it optimized for the kind that's best for it.
I think this is very arguable. For the cases where you want to do some query optimization, thats what the Clojurize protocol's prompt function is intended for.
(prompt
[adapter expression]
"Execute a native database expression")
- weavejester 16y agoBut a more specific library would be better able to cope with the unique features of a particular database. Why send commands via 'prompt' when a more specialised library will have functions to do that job? I think there's definitely a place for libraries that add things like validation to models. But the more functionality you include, the more specific your library needs to be.
- alrex021 16y agoCorrect me if I'm wrong here but isn't that the purpose of the adapter implementations to also hold the different dialect and/or datastore specific optimizations? [edit] OT to this thread: didn't clojure-dbm have some similar ideas to Clojurize? I remember forking it from your github repository early last year some time and doing some cool stuff with it.
- weavejester 16y agoAll of the implementations you mention sacrifice specific functionality in order to support a general interface. For instance, clojure-dbm was an interface to key/value stores, so it supported a small subset of common functionality: fetch, put and delete. It didn't support functions that are specific to a certain type of database, such as setnx in Redis.