couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matteo Caprari <matteo.capr...@gmail.com>
Subject Re: sample couchdb application
Date Fri, 08 Jan 2010 22:12:04 GMT
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 <jchris@apache.org> wrote:
> 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
>



-- 
:Matteo Caprari
matteo.caprari@gmail.com

Mime
View raw message