that's very clever, bravo :) I'll get back to the votes topic after I'll have digested the authentication and I'll try to get one of the two schemes to work.
-teo On Fri, Jan 8, 2010 at 7:38 PM, Chris Anderson <[email protected]> wrote: > On Fri, Jan 8, 2010 at 10:43 AM, Matteo Caprari > <[email protected]> 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 <[email protected]> wrote: >>> On Fri, Jan 8, 2010 at 4:46 AM, Matteo Caprari <[email protected]> >>> 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 >>> >>> 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=true >>> >>> 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 <[email protected]> wrote: >>>>> On Sun, Jan 3, 2010 at 4:57 AM, Matteo Caprari <[email protected]> >>>>> 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 >>>>>> [email protected] >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Chris Anderson >>>>> http://jchrisa.net >>>>> http://couch.io >>>>> >>>> >>>> >>>> >>>> -- >>>> :Matteo Caprari >>>> [email protected] >>>> >>> >>> >>> >>> -- >>> Chris Anderson >>> http://jchrisa.net >>> http://couch.io >>> >> >> >> >> -- >> :Matteo Caprari >> [email protected] >> > > > > -- > Chris Anderson > http://jchrisa.net > http://couch.io > -- :Matteo Caprari [email protected]
