incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf Nieuwenhuijsen" <>
Subject Re: Relying on revisions for rollbacks
Date Sat, 12 Apr 2008 02:36:12 GMT

I've joined this mailing-list, because i wanted to reply to this discussion
I was hoping you could clear a number of things up for me.

1. Why make compacting the default? Isn't more likely that in this day &
age, most will prefer revisions for all data?
2. Compacting seems like very specific behavior, wouldn't a built-in
cron-like system be much more generic? It could allow for all kinds of
background proccessing, like replication, fulltext-search using javascript,
compacting, searching-for-dead-urls, etc.
3. Is support for some sort of reduce behavior, as part of the views,
planned and ifso, what can we expect?
4. What is the default conflict behavor? Most recent version wins?
5. Is it possible to merge on conflicts, or ifnot, how could attachments
possible properly model revisions. Wouldn't we loose a whole revision tree?
6. Without merging, we need to store revisions in seperate documents,
thereby prohibiting usefull doc-is for documents under revision.
7. What added benefit do manual revisisons have when we can just store extra
revision data to each document anyway?

I'm quite sure my understanding of CouchDB can be lacking. But to me it
seems like garantueed revisisions are the killer feature.

The alternative of a cron-like system, could work much like the
view-documents. These documents could contain a source url (possibly local),
a schedule-parameter and a function that maps a document to an array of
documents that is treated as a batch-put. This way we could easily setup
replication, but also all kinds of delayed and/or scheduled proccessing of

Likewise, being able to define a conflict function that could merge data or
decide who wins, seems like a much better alternative to the 'atomic'
batch-put-operations, that break down when distributed. (thereby no longer
garantueeing the scalability; another killer-feature).

Ralf Nieuwenhuijsen

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message