couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wout Mertens <>
Subject Re: behavior of document revisions
Date Thu, 19 Mar 2009 08:55:15 GMT
On Mar 19, 2009, at 1:53 AM, Anand Chitipothu wrote:

> I came across an earlier discussion on "behavior of document
> revisions"[1], which says that:
>> A revision in CouchDB is meant to be used to test if a document has
>> changed since the last time you looked (useful for async updates
>> example) and not to actually look back in time at the document.
> [1]:
> Does it mean that if I want to create a wiki, I have to manage my own
> document revisions? Like shown in this blog post[2]?
> [2]:

Yes. Note that you have some choice about where and how to store  
history. You can store the full contents of old versions or just the  
diffs that will get those; you can store the history in the document  
or in separate documents.

> I tried to extend the wiki idea in [2].
> Here are my views assuming that every page has path, title, body and  
> revision.
> {
>    "_id": "_design/wiki",
>    "language": "javascript",
>    "views": {
>        "page": {
>            "map": "function(doc) { emit([doc.path, doc.revision],  
> doc)}"
>        },
>        "by_title": {
>            "map": "function(doc) { emit(doc.title, doc)}",
>            "reduce": "function(key, values, rereduce) { var doc =
> {'revision': 0}; for (var i in values) if (values[i].revision >
> doc.revision) doc = values[i]; } return doc; }"
>        }
>    }
> }
> Actions:
> * get latest version of a page:
> /wiki/_design/wiki/_view/page?startkey=["foo",
> "Z"]&descending=true&limit=1

Shouldn't that be /wiki/_design/wiki/_view/page? 
endkey=["foo","Z"]&descending=true&limit=1 ? I didn't test this. BTW  
hopefully we'll get open-ended searches before 0.9.0 lands which would  
make this query prettier.

> Is this is the right approach?

I think so although your database will grow large when you get a lot  
of small changes to large pages.

> I'm not quite happy with the above implementation of by_title as it is
> indexing all the revisions, which is unnecessary.

If it doesn't index all revisions, how does it know which is the  
latest one?

You could make the latest version of a document be the one with the  
_id equal to the name. You'd have to store a copy or a diff before you  
store changes to it though. Using that approach you wouldn't need the  
by_title view.

Another approach: make _id be equal to "name<reserved char>version",  
for example disallow the use of # in wiki names and store version 2 of  
a page called foo as "foo#2". Then if you simply GET /wiki/_all_docs  
(with view filters) you can get all revisions of a document, no views  
needed. You'd get the latest version with the same limit=1 approach.


View raw message