couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: sample couchdb application
Date Fri, 08 Jan 2010 17:29:49 GMT
On Fri, Jan 8, 2010 at 4:46 AM, Matteo Caprari <> wrote:
> Hello again.
> Two questions.
> 1. Why the _update functions can't accept POST? That would make it
> possible to send documents
> using just plain html forms, provided that the function can then
> decody the request body.

_update will accept POST or any other HTTP method

> 2. I'm about to add support for voting questions. A vote is a number
> that a user can bump up or push down.
> It can be done by
>   (A) adding one document for each vote
>   (B) having a 'votes' property on each question document
>   (C) one 'votes' document for each question document
> I'd pick B and have the client send votes to an _update handler,
> always updating the latest revision in the database, regardless of the
> document revision
> a user is voting on.
> The only problem with that is conflict resolution in case of document body edit:
> - User starts editing a question body.
> - In the meantime other users vote the question up and down, causing
> the rev number to change.
> - User submits his changes and is alerted that there is a conflict.
> Only it's not a real conflict because a different aspect of the
> document
> has been edited.
> If the client holds a copy of the original document, it could
> automatically merge the documents, or maybe have _update handler do
> that.
> Does this make any sense?

To me it seems simpler to do option A and use a reduce to find the
total votes for each question. This won't make it easy to order
questions by number of votes but it does completely eliminate any
concurrency issues. This method will also be more resilient in a
decentralized application, because votes done at

will reflect on pages at

as soon as they are replicated.

In the counter bump case they will not properly merge but instead will
cause conflicts.


> On Sun, Jan 3, 2010 at 7:07 PM, Chris Anderson <> wrote:
>> On Sun, Jan 3, 2010 at 4:57 AM, Matteo Caprari <> wrote:
>>> Hello list.
>>> I've cranked up a simple couchapp that mimics (if you squint).
>>> The idea is to understand couchdb better and provide the base for a
>>> tutorial, but
>>> before going any deeper, I'd like to hear from you what is wrong and
>>> what is good.
>> This is great stuff. Really cool. I still don't understand all of how
>> you've integrated things, but the documentation is really a great
>> addition.
>> I think this is a really cool use case. Thanks for sharing!
>> One concern I have is that I don't think you need to be building
>> custom _ids. You should be able to accomplish your lists and shows
>> without messing with custom ids, instead using document parameters in
>> views. Custom ids generally just add code-overhead to apps and
>> increase the chances of spurious conflicts.
>> To avoid double posts, PUT with a random docid should be idempotent,
>> and fail on duplicate PUTs. If you can't do PUT from your client the
>> _bulk_docs POST api should work to, if you specify ids. See how
>> jquery.couch.js has an API for getting UUIDs from the Couch and then
>> using them on new docs.
>> Also, in trunk _show is no longer happy to have bogus ids, you'll get
>> a 404. You can invoke with no docid at all to accomplish your use
>> case.
>> I'm happy to help more so that when you write your tutorial it
>> embodies best practices. Just post any questions to this thread!
>> Cheers,
>> Chris
>>> So please have a look, but don't expect too much.
>>> Demo:
>>> Docs:
>>> Source:
>>> Docs are created with jsdoc-toolkit and a custom template.
>>> I think we could integrate it with couchapp to obtain a "view source" feature.
>>> --
>>> :Matteo Caprari
>> --
>> Chris Anderson
> --
> :Matteo Caprari

Chris Anderson

View raw message