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 22:15:46 GMT
On Fri, Jan 8, 2010 at 2:12 PM, Matteo Caprari <matteo.caprari@gmail.com> 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 <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
>



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

Mime
View raw message