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.
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]
