couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: show/list
Date Fri, 15 Nov 2013 03:27:51 GMT
On Fri, Nov 15, 2013 at 6:44 AM, Filippo Fadda
<> wrote:
> On Nov 15, 2013, at 3:06 AM, Alexander Shorin wrote:
>> It's always possible to imagine situation when some tool will be
>> useless and some other handy and good (: CouchApp is no more, but
>> group of design functions as single logical application, that CouchDB
>> easily hosts and able to execute by users request. To interact with
>> other system or remote services you may use external handlers. To run
>> custom background services os_daemons helps much. All these are
>> CouchDB features that could be used to solve specific problem. Not
>> sure why you're trying to avoid them all.
> I'm not trying to avoid them, at least not all of them.
>> While votes are ok
> Votes are OK, but you can't use a show handler to generate the HTML that renders the
article properties (title, body, etc.) and the sum of his votes. Instead, working with ElephantOnCouch
(or any other clients) you can do that. And you can join documents even if they haven't a
score, because ElephantOnCouch (only it) returns records for keys don't match any documents.
And this is free, it's just a query option. I want add this feature to CouchDB also, but since
I'm an Erlang noob, I found easier implement it in my library.

I think the main error is to try to get whole result with single query
as you always does with SQL databases. That's wrong way to go. Let's
see what we have there:

1. show handler to generate the HTML that renders the article
properties (title, body, etc.) - correct

2. the sum of his votes - this is view function and yet another
request from client. Join data on client side, not on server.

So you have one show function that returns HTML response with some
javascript that callbacks on body load view function to get the votes
number. This is good application design to have each part of
application be standalone and through their aggregation/combination
create powerful applications. KISS, DRY and SRP in action.

>> , but having article hit as document isn't wise
>> approach: to note why share your app url on /. , /r, hn or other
>> resource which could generate a lot of hits - you'll quite soon
>> realise that some front-end proxy required to buffer updates and
>> forward them to CouchDB as bulk update.
> You don't need that. In the Article class there is method named getHitsCount() that query
Redis (using the document id) and returns the impressions count. As I wrote in the mailing
list, ElephantOnCouch saves objects and recreates their instance when you get them with the
getDoc() method. This is an elegant approach. Actually Article is a subclass of Post, etc.

We have two different approaches:
- yours to generate hit counts on server side
- mine to provide additional API for clients to get hit counts using
different http resource. You may call it, you may not. If redis is
unavailable you don't care at all since your client got the article
already, just without hits count.

But no one is good since all depends from what requirement are applied
to the project.


View raw message