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 02:06:01 GMT
On Fri, Nov 15, 2013 at 5:49 AM, Filippo Fadda
<> wrote:
> On Nov 15, 2013, at 2:13 AM, Alexander Shorin wrote:
>> Need some example.
> A simple one. Reddit, votes per post.

Vote as document is ok.

>> Certainty, your users may ask to add missiles control panel for their
>> blogs, but sometimes you need to say "no" for features, that goes
>> beyond of your project idea. If they still are within it and you got
>> some design issues: may be something wrong with it.
> You can't even know what a client is gonna ask you or where the business is gonna drive
you. You can just make speculations.
>> If you aware, document updates for CouchDB have high cost (time and
>> disk space), so this is the last thing how you'll use CouchDB. To
>> count article views you need setup external handler that will act as
>> HTTP proxy to redis and trigger it on every article load by browser.
> I'm aware, but this is not the point. I'm trying to demonstrate there are cases where
CouchDB doesn't fit the requirements and others (more often) a couch app doesn't. Put Redis
aside CouchDB is easy, using a framework aside a couch app is not a viable solution.

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.

> You can replace impressions with votes. To avoid conflicts you save each vote as a separate
document, to get the score you need to assemble the article and a _sum result. :-)

While votes are ok, 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.

>> Same as for design functions: make them in
>> python/php/ruby/java/clojure and use all power of these languages.
>> Even for additional querying CouchDB on your risk since this is wrong
>> way to go!
> Of course, I can modify my query server to use ElephantOnCouch, but like you said, it
is not the right way to go and I don't see a use case for it. If I have some heavy elaboration
task, I can use a daemon, I can use Gearman and execute a PHP job inside it.

But this open doors for you also to rich php library set which may be
quite useful, right?


View raw message