On Fri, Jan 8, 2010 at 2:12 PM, Matteo Caprari <[email protected]> wrote: > 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. >
if you wait a few hours I'll have posted a basic screencast introducing the authentication features in couchdb 0.11 the default is sensible and should prevent you from having to write any code. > -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] > -- Chris Anderson http://jchrisa.net http://couch.io
