> 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")

But 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.

Correct 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.

All 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.

I agree to some extent, but most of the time all you want is generic data. What is used to get that generic data and turn it into some format that you can consume (be those objects of data structures) is irrelevant.