Working on a CouchDB type

107 views
Skip to first unread message

Chas Emerick

unread,
Dec 16, 2011, 7:52:26 AM12/16/11
to clojure...@googlegroups.com
```
Clutch provides a pretty comprehensive API, but I'm frustated that 95% of database
interactions require using something other than the typical Clojure vocabulary of
assoc/conj/dissoc/get/seq/reduce/etc, even though those semantics are entirely appropriate
(modulo the whole stateful database thing).

This is (the start of) an attempt to create a type to provide most of the
functionality of Clutch with a more pleasant, concise API (it uses the Clutch API
under the covers, and rare operations would generally remain accessible only
at that lower level).
```

Read more and see a REPL listing demoing what I've built so far:

https://gist.github.com/1485920

Look interesting, useful, weak?

Cheers,

- Chas

Sam Ritchie

unread,
Dec 16, 2011, 12:46:57 PM12/16/11
to clojure...@googlegroups.com
I'm all for this; a solid attempt at proper clojure semantics absolutely beats the half efforts I've been making in my own code to implement get, update, etc.
--
Sam Ritchie, Twitter Inc
@sritchie09

(Too brief? Here's why! http://emailcharter.org)

Chas Emerick

unread,
Jan 25, 2012, 1:54:14 PM1/25/12
to Clojure Clutch
FYI, this is now available in [com.ashafa/clutch "0.3.1-SNAPSHOT"].
Very early documentation in the readme:

https://github.com/clojure-clutch/clutch

(Note that github's asciidoc rendering of code blocks is broken at the
moment, so the example REPL interaction is totally borked at the
moment. The API hasn't really changed since I posted https://gist.github.com/1485920
though.)

Feedback most welcome!

- Chas

On Dec 16 2011, 7:52 am, Chas Emerick <cemer...@snowtide.com> wrote:
> ```

hank

unread,
May 25, 2012, 11:32:14 AM5/25/12
to clojure...@googlegroups.com
Hi,

Not sure essentially aliasing "put-document" with "conj" is a big win. And that the whole database is somehow stateful because of documents getting added or removed doesn't make it un-Clojure-ish IMHO, it's like saying Clojure is stateful because you can create new vars at runtime or something like that. What makes CouchDB unclojureish stateful is that you can "modify" individual documents by adding/removing/changing fields and causing a slew of revisions to happen.

So for my current CouchDB application I am trying to arrange state in a more true Clojure kind of way. Documents are immutable (only one revision ever), link to one another by specifying one doc's ID in one of another one's fields and changes are allowed only on special kinds of mutable docs (think refs in Clojure) which are in the minority. The linked docs form "data structures" like lists and trees. In some cases, views or filtered replications provide the role of "mutable doc/ref" so they aren't even explicitly required.

This IMHO provides a good degree of control over replication (sharding) and therefore efficiency although that statement yet has to be backed up by numbers.

However, why stop here? Why not go further and say if I want my DB to be like a Clojure map, can't the Clojure map just *be* the DB? As in, an in-memory database based on Clojure data structures, that can be replicated to/from CouchDB instances or just amongst one another? With e.g. Prevayler-style logging/snapshotting persistence? (also cmp. my comment on Datomic here)

This would also fit well with the upcoming "CouchDB light" databases like TouchDB and PouchDB one use case of which is to just manage caches of data from a server held for temporary offline access. You might even get away with not having persistence in those cases.

-- hank

Chas Emerick

unread,
Jun 3, 2012, 8:52:11 AM6/3/12
to clojure...@googlegroups.com
Hi Hank,

My efforts with the type aren't an attempt to reconcile CouchDB with Clojure's typical immutable semantics (despite my loosely-worded first message on this thread).  Indeed, the type defines a fn `conj!` (along with `assoc!` and `dissoc!`) — not `conj` — since CouchDB can at best be characterized as a degenerate transient collection.

I think another library (perhaps using Clutch as a low-level dependency?) that attempts to provide immutable, persistent semantics backed by CouchDB would be interesting.  (In some sense, I may have just described Datomic, backed by CouchDB for storage?)

Cheers,

- Chas

hank

unread,
Jun 3, 2012, 9:41:42 AM6/3/12
to clojure...@googlegroups.com
Yes that would be somewhat like Datomic, backed by CouchDB storage. Btw I realize that in my earlier post I wrote "see my comment on Datomic here" but "here" was supposed to be a link: here.

Of course Datomic isn't Free and what's more important, doesn't have P2P replication/sharding which for me is the whole raison d'être for CouchDB. I use it with mobile devices and offline machines.
Reply all
Reply to author
Forward
0 new messages