couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: show/list
Date Thu, 14 Nov 2013 23:36:46 GMT

I believe we have different experience in background and we're talking
about abstract tools features, not solving some real problem, so this
discussion going to be pointless.

On Fri, Nov 15, 2013 at 3: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. :-)

Yes, you can!(: Since we hadn't define any task to solve with these tools.

> 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.

Certainly, they couldn't be compared since CouchDB explicitly strict
you within single document or view result namespace. Sometimes this
only leads to more clear design since you're not able to make cross
references between different logical objects. This is how
document-databases design works and I'm sure that if you need joins on
server side probably you have wrong data design.

Certainly, with plain ruby and rails you can do much more things that
with only CouchDB design functions. But again, if your task could be
implemented as couchapp - what's the reason to setup additional
application tier in front of CouchDB?

Btw, if you share interesting idea of the app that you think isn't
possible to be done as couchapp I'll make tutorial for docs based the
solution (:
Currently this is going to be issue tracker, interesting enough?

>> 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.

Postgresql has all of this (ok, replication is master-slave, but still
it fault tolerant enough) and it's blindly fast, even faster than
mongo for JSON data, but much more stable. Why do I have slow HTTP
requests to database on my backend? Nonsense. Everything else could be
easily done on rails side, as you pointed above.

>> 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.

Well, and how they different from show/list/update functions and
commonjs modules? Not in implementation details, but in spirit of the
task they aimed to solve.


View raw message