couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: sample couchdb application
Date Fri, 08 Jan 2010 19:38:03 GMT
On Fri, Jan 8, 2010 at 10:43 AM, Matteo Caprari
<matteo.caprari@gmail.com> 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 <jchris@apache.org> wrote:
>> On Fri, Jan 8, 2010 at 4:46 AM, Matteo Caprari <matteo.caprari@gmail.com> 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 <jchris@apache.org> wrote:
>>>> On Sun, Jan 3, 2010 at 4:57 AM, Matteo Caprari <matteo.caprari@gmail.com>
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
>>>
>>
>>
>>
>> --
>> Chris Anderson
>> http://jchrisa.net
>> http://couch.io
>>
>
>
>
> --
> :Matteo Caprari
> matteo.caprari@gmail.com
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message