It worked. yay. this paves to way to dismiss natural ids, which as per your prediction proved to be a pain and to require very careful escaping to avoid breaking links.
I don't understand the clock drift problem. When a new question is created I copy the timestamp as a string from an object to another. I need to digest your observation about the validation thing, but for now I think it's not an issue because all answers go trough an _update handler. Thanks for the _id trick, It turned out useful to batch update all answer with question_created field. You may want to penjoy the output at: http://caprazzi.net:5984/fortytwo/_design/fortytwo/_list/questions_index/questions_index?descending=true great support, thanks. On Wed, Jan 6, 2010 at 9:42 PM, Chris Anderson <[email protected]> wrote: > On Wed, Jan 6, 2010 at 1:04 PM, Matteo Caprari <[email protected]> > wrote: >> Hi. >> >> About the second view, what about denormalizing and copying question >> creation time in each >> answer? I could then map like this to have each question followed by >> it answers, all in question creation order. >> >> emit([ >> doc.question_created_at, >> doc.question_id, >> (doc.question) ? 0 : 1], doc) > > That's good. I hadn't thought of that. > > One concern is clock drift between clients. Another is validating that > the client hasn't changed the question_created_at. > > You could keep the answers in approximate chronological order too, > with something like: > > if (doc.question) { > emit([ > doc.question_created_at, > doc._id, 0], > {"_id" : doc.author_info_id ,question : doc.question}); > } else if (doc.answer) { > emit([ > doc.question_created_at, > doc.question_id, doc.doc.answer_created_at], > {"_id" : doc.question_id, answer : doc.answer}); > } > > Emitting an _id in your value will direct include_docs to load an > alternate document from the database depending on the value -- if you > don't emit one, it acts like you emitted {"_id" : doc._id}. This is > one way to build a smaller index with more flexible querying options. > > For your app, clients could validate the question doc's created_at > with the answer's question_created_at, and ignore rows that don't > match. > >> >> Is denormalizing normal on the couch? > > Yes, and your foreign timestamp thing is clever. I'm interested to see > how it turns out. > > Chris > >> >> On Sun, Jan 3, 2010 at 9:31 PM, Chris Anderson <[email protected]> wrote: >>> On Sun, Jan 3, 2010 at 12:03 PM, Matteo Caprari >>> <[email protected]> wrote: >>>> Hi Chris. >>>> >>>> I haven't actually integrated nor automated anything: I run jsdoc >>>> manually before each redeploy. I'm looking into an >>>> integration with couchap but christmas got in the way and accomplished >>>> nothing yet. >>>> >>>> I think I had some problems with ordering by question date because answers >>>> don't >>>> have the question timestamp and didn't know what key to emit to keep >>>> the item adjacent. >>> >>> The way I handle this in Sofa is by having two views: >>> >>> One would be all questions by date. >>> >>> The other is questions together with answers by date. (The question >>> and answer groups are in this view in a random order). >>> >>> There's no sane way to do the second view with the questions also >>> sorted by date... >>> >>> Chris >>> >>>> >>>> But I like your optimism, so I'll try my head again and maybe ask again. >>>> >>>> I'll sync the app with your suggestions and post the results to this >>>> thread. >>>> >>>> thanks for your support. >>>> >>>> On Sun, Jan 3, 2010 at 7:07 PM, Chris Anderson <[email protected]> wrote: >>>>> On Sun, Jan 3, 2010 at 4:57 AM, Matteo Caprari <[email protected]> >>>>> 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 >>>>>> [email protected] >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Chris Anderson >>>>> http://jchrisa.net >>>>> http://couch.io >>>>> >>>> >>>> >>>> >>>> -- >>>> :Matteo Caprari >>>> [email protected] >>>> >>> >>> >>> >>> -- >>> Chris Anderson >>> http://jchrisa.net >>> http://couch.io >>> >> >> >> >> -- >> :Matteo Caprari >> [email protected] >> > > > > -- > Chris Anderson > http://jchrisa.net > http://couch.io > -- :Matteo Caprari [email protected]
