incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Alfke <>
Subject Re: show/list
Date Thu, 14 Nov 2013 23:56:01 GMT

On Nov 14, 2013, at 2:19 PM, Benoit Chesneau <> wrote:

> I have examples in prod that shows that not anyone is sharing the same
> opinion as you ;) There are plenty of example where lists and shows can be
> used.

I’m sure there are. They’re just not particularly useful when the database is embedded
inside the app. The kind of postprocessing list/show functions do is useful when the client
and server are widely separated since it saves you a lot of round-trips and can massage data
into the form a client expects. That’s not an issue when the app and db live within the
same process.

> Where
> the use of lists and shows, the fact that you can replicate them (which is
> possible when you use ios and android outside the app store in entreprises
> or private events) is a huge advantage.

You can implement list/show functions outside the database. You can even put them in a library
function in your CouchApp and replicate them that way. They’re just handy utilities, not
actual database functionality.

> Why some person are using
> SQL? Because they can query the data. Why woud you like to have shows and
> lists or any feature like this? Because you eventually build your own way
> to query your data.

I’m not saying the ability to postprocess query results isn’t useful. I’m just saying
that list and show functions are a hacky way to do it. They remind me of old CGI programs
that painstakingly assembled HTML by string concatenation, instead of using something like
a template language. And the fact that they’re manipulating the results in text form makes
them inefficient and prone to errors. Ideally you’d transform the data directly as objects
instead of having to convert them into text that then gets parsed by something else.

View raw message