couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: show/list
Date Fri, 15 Nov 2013 00:37:49 GMT
On Fri, Nov 15, 2013 at 12:06 AM, Filippo Fadda <> wrote:

> On Nov 14, 2013, at 9:34 PM, Alexander Shorin wrote:
> > Why I do need PHP or Ruby, when CouchDB is able to do the same without
> > them?(: Having yet another technology in whole system only raises his
> > complexity and reduced fault tolerance.
> CouchDB is not able to do the same, neither is JavaScript used in
> combination with list and show only. You can use Backbone, Mustache,
> Node.js, but it's like using Rails or any other framework, with the
> exception it's JavaScript. OK, you like JavaScript, go with the above
> technologies but don't tell I can do the same just with CouchDB, because is
> a lie. :-)
> You can't compare the features of a full stack framework with the list and
> show handlers provided by CouchDB. IMO couch apps are just a joke, real
> applications are quite different. For me a couch app is an application
> stored and served by CouchDB, not an application written in JavaScript.
> For example you can't inside a show, query CouchDB to get correlate data
> and assemble them to provide a result. Neither you can do it in a list. And
> don't tell me you can write your views to return all the documents you need
> with just one query, because you can't, this is not a real scenario.

First shows and lists can be handled in a langage different that JS.

I agree *now* you can't  "correlate data and assemble them to provide a
resut". But this is now. Nothing stop us to add such features. Nothing stop
us to improve it so it can be more useful. As I said previously it should
be easy to do it.

> > Yes, if I'm using any mentioned framework I'll better take Postgresql
> > (omg, what I'm say!) since now my database is just database, not
> > application server like CouchDB is.
> No if CouchDB fits your needs. When you need fault tolerance, scalability
> and replication for free, you may go with CouchDB. I think DB in CouchDB is
> there for some reason, else it would call CouchApp Server...
> There are plenty app servers out there better than CouchDB, but I don't
> see any other database like CouchDB, built on the same concepts. And
> sincerely I didn't approach CouchDB because I wanted an application server.

Again shows and lists are not related to couchapps.

> > P.S. We have different use cases and there are different requirement
> > are applied to CouchDB to his features. Like with those Postgresql why
> > do you need PL/pgSQL feature when you can do the same on your app
> > side?
> PL/SQL is something serious, it has been created to write stored
> procedures. And stored procedures still make sense nowadays, even if the
> application logic is not anymore in the database. Please, you can't compare
> show and list as they are actually with stored procedures. I have a 1000
> pages book just describing Oracle PL/SQL and it's a 15 years old.
If I hear you you wouldn't have an new technology . lists and shows are not
a joke. You can call them unfinished concept, work in progress, but some
people like me consider it is serious.

The concept of processing and transforming data is related to the concept
of database. All the databases does that via the queries or stored
procedure. Shows and lists are literally a way to query a function on your
database to retrieve some results from the data stored in it. Couchdb is
not yet a functional db but it can be modulo some changes.

Example of improvement: having something like in datomic allowing you to
post your data with an atomic function  to make some changes on the data
you posted based on the current database value looks like the updates
function but is quite better. This is an improvement that could be done.

In postgres you have the possibility to extend the database functions and
queries using foreign language wrappers. Quite similar to shows and lists.
But we should make it more efficient.

Anyway you should really look further than the current status quo on the
data stack and the way people think they should handle data. You should
also realise that all the layers you add to your database (on top or
behind) are difficult to maintain and deploy.

- benoit

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message