incubator-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 12:46:24 GMT
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.

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?

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

Mime
View raw message