From user-return-8366-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Fri Jan 08 19:38:38 2010 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 95393 invoked from network); 8 Jan 2010 19:38:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Jan 2010 19:38:38 -0000 Received: (qmail 34891 invoked by uid 500); 8 Jan 2010 19:38:37 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 34817 invoked by uid 500); 8 Jan 2010 19:38:37 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 34807 invoked by uid 99); 8 Jan 2010 19:38:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jan 2010 19:38:36 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=SPF_PASS,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates 209.85.222.182 as permitted sender) Received: from [209.85.222.182] (HELO mail-pz0-f182.google.com) (209.85.222.182) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jan 2010 19:38:25 +0000 Received: by pzk12 with SMTP id 12so5014550pzk.13 for ; Fri, 08 Jan 2010 11:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=dB2CxsBj1dWKRXh95uNT69793MaTblkhf8y7USx6L7c=; b=s3cFnZCr2+NWxeNuIZRgNZ7ND8ca95PLvwmWUWlGP7UDudUroXFmptvaqyKE49DOs3 zQRYFUwigB4nUdIhg5D66iePjRC4uwTUUQQvNCWn9DB0pN/7RJ9aJ/F9BSy9OwTo6dIb E4w281gNW28cS5ZAjcNnjf6OJrRyKy+P15b+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=CjL+cM+OhMBwjVesENsPNbyQnkQZvChT5egiSgrl8ZvjtuxEXQcceLzlHrv613Hg5R BM4dxasHoVwEn8tCG82UA+qd4PFuuv34AR6+UPwb9kY/velc/XR/+Hewuvhz0BYbcAFP tSCcXDv8BW5mv6dMJCemk/9zRMA7DC/TrHRQ8= MIME-Version: 1.0 Sender: jchris@gmail.com Received: by 10.142.9.24 with SMTP id 24mr302650wfi.235.1262979483836; Fri, 08 Jan 2010 11:38:03 -0800 (PST) In-Reply-To: <1bca98391001081043t3ae15142p8e2704bdff9aed1@mail.gmail.com> References: <1bca98391001030457m52aca7d8lf77edd06375f41c6@mail.gmail.com> <1bca98391001080446j5d8244c3r517f9e23bfdb8c88@mail.gmail.com> <1bca98391001081043t3ae15142p8e2704bdff9aed1@mail.gmail.com> Date: Fri, 8 Jan 2010 11:38:03 -0800 X-Google-Sender-Auth: d98db189ab2859e0 Message-ID: Subject: Re: sample couchdb application From: Chris Anderson To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Fri, Jan 8, 2010 at 10:43 AM, Matteo Caprari wrote: > At some point I'll have to enforce a one-vote-for-user-for-document > policy. This makes option B out of the question as main votes storage > logic; it may still be useful as a denormalized view to make listing > easier. One thing you can do in option A with a reduce, is to count multiple votes from a user for a question, only once. So the user could try to hack the system by creating lots of docs, but they'd never see the # actually go up. The obvious way to do this (masking the sum so it only counts each user once) only approximates the solution, but it should be "good enough." The airtight way (counting the unique # of users who voted) involves a little more data transfer, but should work regardless of the # of votes. > > Considering also chris' observations, option A seems the frontrunner, > followed by a new option > > (D) one user-votes document that holds all user votes > > In the meantime I've done it using option B for both questions and > answers. It was the faster silver bullet to get a sense of the > problems involved. > > Even recognizing couchdb's mind boggling potential as a p2p > application server, I wasn't quite sure that it could deliver stuff > for the real world. I now can't wait to see what it's going to be in 5 > years :) > > -teo > > On Fri, Jan 8, 2010 at 5:29 PM, Chris Anderson wrote: >> 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 >>> =A0 (A) adding one document for each vote >>> =A0 (B) having a 'votes' property on each question document >>> =A0 (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 b= ody 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 >> >> http://jchrisa.net/forty2/_design/fortytwo/docs/index.html >> >> will reflect on pages at >> >> http://caprazzi.net:5984/fortytwo/_design/fortytwo/_list/questions_index= /questions_index?descending=3Dtrue >> >> as soon as they are replicated. >> >> In the counter bump case they will not properly merge but instead will >> cause conflicts. >> >> Chris >> >>> >>> On Sun, Jan 3, 2010 at 7:07 PM, Chris Anderson wrot= e: >>>> On Sun, Jan 3, 2010 at 4:57 AM, Matteo Caprari wrote: >>>>> Hello list. >>>>> >>>>> I've cranked up a simple couchapp that mimics stackoverflow.com (if y= ou 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: http://caprazzi.net:5984/fortytwo/_design/fortytwo/index.html >>>>> Docs: http://caprazzi.net:5984/fortytwo/_design/fortytwo/docs/index.h= tml >>>>> Source: http://github.com/mcaprari/fortytwo >>>>> >>>>> 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 >>>>> matteo.caprari@gmail.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Chris Anderson >>>> http://jchrisa.net >>>> http://couch.io >>>> >>> >>> >>> >>> -- >>> :Matteo Caprari >>> matteo.caprari@gmail.com >>> >> >> >> >> -- >> Chris Anderson >> http://jchrisa.net >> http://couch.io >> > > > > -- > :Matteo Caprari > matteo.caprari@gmail.com > --=20 Chris Anderson http://jchrisa.net http://couch.io