Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 31952 invoked from network); 8 Jan 2010 12:47:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Jan 2010 12:47:17 -0000 Received: (qmail 30212 invoked by uid 500); 8 Jan 2010 12:47:16 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 30144 invoked by uid 500); 8 Jan 2010 12:47:16 -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 30134 invoked by uid 99); 8 Jan 2010 12:47:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jan 2010 12:47:16 +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 (athena.apache.org: domain of matteo.caprari@gmail.com designates 74.125.78.26 as permitted sender) Received: from [74.125.78.26] (HELO ey-out-2122.google.com) (74.125.78.26) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jan 2010 12:47:05 +0000 Received: by ey-out-2122.google.com with SMTP id 22so129484eye.41 for ; Fri, 08 Jan 2010 04:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=iW0IcKxH1w1aE0PPewQINQ6wUDWBRK7m13Bph6P3KhI=; b=iLT5KAl8g8IR27H6SvGMHXNW3llihDW9kCNx5+jKlQAIj9Vxcal493D7+vRBOX0wN0 LhP5CXNaNohH4dWyZbhEudjepnahOKL0UAoeawDKwH8AFjWO04EzbMudMRbr2YTCpMcD S5RHJPGRlz9D+qVCFu6fguoUv8xM+2gJYOwic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=WDl0yEbjiShFsjWb1rp5zQjn3mBuTlj/2PlELIoC97TyPSAZ3dT6xDnxC0dvTcvrit CGz7xmLkgFQRtalEPTl61hW4Hpwa1/58WYP8ZTvPA8Rb6StxJzlyhJ6rrNmNrDyYw95T eDxf89KXW5ZtOc1vcwr+Omp9rnR0+5p/2X0GQ= MIME-Version: 1.0 Received: by 10.216.87.83 with SMTP id x61mr3435028wee.7.1262954804167; Fri, 08 Jan 2010 04:46:44 -0800 (PST) In-Reply-To: References: <1bca98391001030457m52aca7d8lf77edd06375f41c6@mail.gmail.com> From: Matteo Caprari Date: Fri, 8 Jan 2010 12:46:24 +0000 Message-ID: <1bca98391001080446j5d8244c3r517f9e23bfdb8c88@mail.gmail.com> Subject: Re: sample couchdb application To: user@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 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. 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? 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 stackoverflow.com (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: http://caprazzi.net:5984/fortytwo/_design/fortytwo/index.html >> Docs: http://caprazzi.net:5984/fortytwo/_design/fortytwo/docs/index.html >> 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