couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Mitchell <>
Subject Re: show/list
Date Thu, 14 Nov 2013 18:30:25 GMT
On Thu, Nov 14, 2013 at 1:24 PM, Benoit Chesneau <> wrote:
> On Thu, Nov 14, 2013 at 6:58 PM, Filippo Fadda <
>> wrote:
>> Any application that uses CouchDB as a pure database doesn't need show and
>> list handlers. They are simply useless, in fact I didn't implement (yet)
>> them in ElephantOnCouch library because I don't see any use case for them.
>> And I'm not sure if I will never implement them, probably not. If you are
>> using Ruby, Python, PHP, you'll never produce HTML directly from CouchDB,
>> because there are frameworks in plenty with template engines aimed to do
>> the job.
>> I don't know the history about show and list, but they remember me Lotus
>> Domino. Of course you need them if you are developing a CouchApp.
>> -Filippo
> On the contrary I think they are very useful for a database. A rather smart
> way to  transform and query the data (doc or views).
> To do a bit of history the first proposal for them had only one handler
> called "form", a way to format the data or send a form.  We settled on a
> simpler form distinguishing docs and views and the way to handle them.
> Sometime after you had the updates functions. They are not per see related
> to the couchapps. You can do couchapps without them.
> On the other contrary lists and shows are a way to handle in memory on the
> server side the results you fetch and provides new results depending on the
> params you pass to the URL. All results can the be streamed to the client.
> They can replace in some cases the queries you can do on some dbs like the
> relational db or some document databases with more capabilities of query by
> default. After all most of a SQL query is handled in memory.
> But actually they have their caveats. They can be slow due to the way the
> JS engine work. The way we can improve this is known (in fact there aremany
> different way: improving the messages between erlang and js, adding a DSL,
> using a native language..). The other thing that should be improved is the
> way the lists are working. For now we can't access to more than one view
> (or secondary index) in a list which means we can't do yet complex queries
> based on multiple index(views) like a relational or others databases like
> datomic can do. Such change should be easy though.
> In short I don;t think we should deprecate such functions. We should on the
> contrary improve them. And stop to associate them to "couchapps". They are
> not.

Do you think such features would fit inside an appropriately crafted
plugin system?

View raw message