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 18:43:00 GMT
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 <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

Mime
View raw message