News for hackers. Stuff that matters.
Re:The Road to CouchDB 2.0 by y0ghur7_xxx on Monday July 25, 2016 @03:12PM (#12160837)
CouchDB is awesome. We evaluated it some time ago¹ and we all thought that the way it worked, the performance, the management are light years ahead of everything else in this space. We ended up not using it because it looked like it was dead. I am so happy that it is not, and I hope this 2.0 release will bring in some more community love. It absolutely deserves it!

¹https://news.ycombinator.com/item?id=11757015

(couchbase sales people came answering, even if couchbase is a completely different product that covers different usecases)

Re:The Road to CouchDB 2.0 by HodGreeley on Monday July 25, 2016 @04:01PM (#12161190)
Seems like you're confusing Couchbase Mobile and Couchbase Server. And that wasn't a sales person that responded. It was the head of Couchbase Mobile engineering.
Re:The Road to CouchDB 2.0 by y0ghur7_xxx on Monday July 25, 2016 @04:44PM (#12161490)
> Seems like you're confusing Couchbase Mobile and Couchbase Server.

Probably. But is that really my fault?

There is CouchDB, CouchIO, CouchOne, Couchbase, Couchbase Server, Couchbase Mobile, Couchbase Lite, CouchApps, BigCouch, Touchbase, Membase, Memcached, MemcacheDB... all different and yet related in a way not at all obvious from the names alone.

First there was CouchDB, a database created by Damien Katz, a former IBM developer. Its official name was changed to Apache CouchDB after it became an Apache project.

A company named CouchIO was founded to work on Apache CouchDB and later changed its name to CouchOne (by "its name" I mean the company name - not the database name).

CouchOne (formerly CouchIO) merged with Membase (formerly NorthScale) to form a new company called Couchbase. Membase (the company) developed Membase (a product of the same name). Membase was created by several leaders of the Memcached project and it used the Memcached protocol. After the merger of CouchOne and Membase, Couchbase continued the development of the Membase software and later changed its name to Couchbase Server.

Today I think most people believe that Couchbase Server is a new version of CouchDB but it is in fact a new version of Membase. It still uses the Memcached protocol and not the RESTful API of CouchDB. Meanwhile CouchDB is still CouchDB, actively maintained and enhanced as an Apache project.

http://stackoverflow.com/a/15184612/512324

Re:The Road to CouchDB 2.0 by merpnderp on Monday July 25, 2016 @03:42PM (#12161053)
I don't think any discussion of CouchDB is complete without mentioning PouchDB. And now that CouchDB will have clustering out of the box, there's all the more reason to support offline versions of your database in your webapps.

https://pouchdb.com/

Re:The Road to CouchDB 2.0 by brightball on Monday July 25, 2016 @01:30PM (#12160154)
Looks like a very solid release. CouchDB has always had that niche as an ultra reliable and steady NoSQL DB while being the best of breed option for offline syncing / healing separated nodes.

It fell behind in terms of perception while Mongo was chasing benchmarks early on but has seemingly continued to just keep chugging along with it's design decisions.

General community, "You sure about that? I mean...benchmarks."

Couch, "Yep...we're sure."

* few years later *

General community, "Have you seen CouchDB? This thing is really solid. Did you ever read that Hacker News thread about how terribly unreliable Mongo is?"

Re:The Road to CouchDB 2.0 by niftich on Monday July 25, 2016 @03:27PM (#12160941)
Mongo had better marketing. They sponsored hackathons, they had great out-of-the-box UX, they filled their homepage with logos of both 'big enterprise' and 'hip startup' companies using it, and were able to present their product in a way to capitalize on the rise of Node.js and the 'NoSQL' keyword hype.

In fact, the 'MEAN stack' was coined by a MongoDB developer on his blog [1], a post which is a perfect example of the kind of marketing, anecdotes, messaging, and strategies that Mongo employed to stay relevant.

[1] http://blog.mongodb.org/post/49262866911/the-mean-stack-mong...

Re:The Road to CouchDB 2.0 by tormeh on Monday July 25, 2016 @02:01PM (#12160375)
MongoDB is written in C++, C and Javascript. CouchDB is written in Erlang. It's not weird that it ended up like this.
Re:The Road to CouchDB 2.0 by markpapadakis on Monday July 25, 2016 @02:07PM (#12160412)
The language, especially the languages you enumerated, rarely have anything to do with the actual final product's qualities (including it performance, reliability and ease of use). Mongo is unreliable because too much effort was spent making it easy to install and use it immediately (it works!) and little to no care apparently went into anything else. Nothing to do with the choice of C++ for Mongo, or the choice of Erlang for Couch.
Re:The Road to CouchDB 2.0 by reddit_clone on Monday July 25, 2016 @02:54PM (#12160723)
I wouldn't be too sure of that. Each language's ecosystem fosters certain ways of approaching and solving problems.

For example, Erlang/OTP brings a lot to the table. Being functional, it would protect you against certain types of errors leaving you free to solve more complex problems. You pay for it with run time performance. String operations are slow etc.

C++ is very fast and very sharp. Not easy to get everything right. (Some sort Greenspun's rule would apply here I think. Substitute Erlang for Common Lisp).

Re:The Road to CouchDB 2.0 by brightball on Monday July 25, 2016 @03:31PM (#12160981)
That's pretty much why Couchbase was created if I recall. He wanted to substitute the parts that could be done faster in C and the benchmarks have proved out well if I recall.
Re:The Road to CouchDB 2.0 by markpapadakis on Monday July 25, 2016 @03:39PM (#12161028)
I understand it is about tradeoffs, and that the benefits and limitations of every language(in terms of syntax and semantics, and its associated runtime/VM -- if any) definitely define to a large extent the final product's characteristics.

I am only saying that Mongo is not unreliable because C++ was selected; it's unreliable because of architectural choices and lack of care which may or may not have been intentional.

Re:The Road to CouchDB 2.0 by tormeh on Monday July 25, 2016 @06:24PM (#12162061)
Crudely put, my point was that the people who freely choose C, C++ and Javascript (and PHP etc.) are the kind of people who don't care much for quality. I understand if there are availability or historic (or even sometimes performance) reasons why someone chose a bad language, but if not I'm a bit prejudiced towards them. Erlang, in contrast to the aforementioned languages, is a language for people who plan to do things properly.
Re:The Road to CouchDB 2.0 by niftich on Monday July 25, 2016 @11:56AM (#12159502)
Summary:

CouchDB 2.0 is a unification of the CouchDB 1.x line (a single-node DB) with BigCouch (which was a fork by Cloudant that added proper out-of-the-box clustering).

Re:The Road to CouchDB 2.0 by reubano on Monday July 25, 2016 @01:20PM (#12160090)
You have no idea how long I've been waiting for this. I seriously thought couchdb was dead. Looking forward to more frequent releases in the future.
Re:The Road to CouchDB 2.0 by doublerebel on Monday July 25, 2016 @12:25PM (#12159720)
I've had great experiences with Cloudant's service and features, this will be a huge boon to the open-source community. I've tried the other Couch flavors and cloud hosts and there is no comparison on features, responsiveness and stability.
Re:The Road to CouchDB 2.0 by sa_su_ke_75 on Monday July 25, 2016 @11:33AM (#12159348)
what are the new changes of 2.0 version?
Re:The Road to CouchDB 2.0 by mark242 on Monday July 25, 2016 @11:52AM (#12159478)
Primarily merging the changes that Cloudant (now an IBM product) made to Couch to turn a fairly simple implementation of NoSQL / MapReduce into a first-class datastore.

Things like:

* Native Lucene search, which you had to build as a weird add-on for Couch. Now it's full-featured out of the box.

* Geospatial queries, also a weird add-on which only kind of worked in Couch, is also cooked in and is pretty strong now.

* True node clustering and data sharding; Couch has always had really really easy replication between nodes, and getting master-master replication is essentially creating a document on each node. However, you had to store your entire data set on every node, which would grow out of control in a hurry.

* A better auto-compactor. Couch 1.6 does fairly well but it's still a weird cron-based thing that can still fail horribly. The auto-compactor in Cloudant/Couch 2.0 is pretty solid and you don't have to worry about massive spikes in disk space consumption.

Re:The Road to CouchDB 2.0 by rakoo on Monday July 25, 2016 @12:59PM (#12159961)
Thanks for this list. One of the pain points of CouchDB was management of users: there is only database-level granularity, which is not enough for many applications (and one-database-per-user may not be practical). I know that Couchbase Sync Gateway uses channels (http://developer.couchbase.com/documentation/mobile/current/...) that look interesting.

Do you know if there has been changes on this side for CouchDB 2.0 ?

Re:The Road to CouchDB 2.0 by y0ghur7_xxx on Monday July 25, 2016 @03:35PM (#12161005)
Managing rights for users on document level granularity was pretty easy in 1.6. A simple js function (it's called a "design document") to handle the logic and you are done. Just an example:

    function(newDoc, oldDoc, userCtx) {
        if (userCtx.roles.indexOf('can-write-sessions') !== -1 || userCtx.roles.indexOf('admin') !== -1) {
            return;
        } else {
            throw ({
                forbidden: 'can-write-sessions role missing'
            });
        }
    }
Why do you think that the Couchbase Sync Gateway is better?
Re:The Road to CouchDB 2.0 by rakoo on Monday July 25, 2016 @06:29PM (#12162084)
Validation functions give you control on writing, but there is no control on reading: everybody can read everything. That's more or less by design, couchdb would encourage you to create another db for another set of permissions.

Couchbase's channels allow you to segregate docs with different read (or write) rights inside the same db.

Re:The Road to CouchDB 2.0 by HodGreeley on Monday July 25, 2016 @03:56PM (#12161150)
It's not just rights, but the ease of doing data routing with channels. For mobile, having a full stack of an embedded mobile db, sync, and backend server solves a lot of problems.
Re:The Road to CouchDB 2.0 by sa_su_ke_75 on Monday July 25, 2016 @01:01PM (#12159978)
Thanks. but i have listen also that there isn't no more need to make replication between a node and another node at level db by hand or automated. But is live if with the cluster i can see a big database replicated on all nodes
Re:The Road to CouchDB 2.0 by mark_l_watson on Monday July 25, 2016 @04:54PM (#12161555)
Cool! One question: CouchDB is written in Erlang and Lucene is Java. So CouchDB is now a dual language project, implementation wise?
Re:The Road to CouchDB 2.0 by spb on Monday July 25, 2016 @07:17PM (#12162289)
I think what they're saying is that it used to be CouchDB -> Addon -> Lucene, where it's now just CouchDB -> Lucene. It still requires a separate component in Lucene; it just doesn't require maintaining another separate component.
Re:The Road to CouchDB 2.0 by _Marak_ on Monday July 25, 2016 @03:56PM (#12161149)
CouchDB has not let me down once in over seven years of production usage.

I'm not sure what other software I could say that about.

Re:The Road to CouchDB 2.0 by lokedhs on Monday July 25, 2016 @11:46PM (#12163197)
Same here. The core of our chat application is centred around CouchDB and RabbitMQ. Neither of which have ever let us down.

It can't be a coincidence that both of them are written in Erlang.

Re:The Road to CouchDB 2.0 by carterschonwald on Monday July 25, 2016 @04:55PM (#12161557)
I'm pretty confused about where the couchdb repo lives. Can anyone point me to it?

Oddly: https://github.com/couchbase/couchdb?files=1 seems to be more like the code than any of the Apache stuff

Re:The Road to CouchDB 2.0 by gtirloni on Monday July 25, 2016 @05:05PM (#12161607)
Re:The Road to CouchDB 2.0 by carterschonwald on Monday July 25, 2016 @07:11PM (#12162265)
No shit. Now explain to me why the Apache version is split into like 20 different rebar git repos but has had some core parts untouched for 1-2 years? https://github.com/apache/couchdb-couch/tree/master/src
Re:The Road to CouchDB 2.0 by mark_l_watson on Monday July 25, 2016 @04:49PM (#12161526)
I am going to give CouchDB another look. I used to use it a lot, and experimented with BigCouch, but I didn't used to like JavaScript, so doing views, etc. was a pain. Now, I don't dislike JavaScript so much and CouchDB fits some use cases I have.
Re:The Road to CouchDB 2.0 by lokedhs on Monday July 25, 2016 @11:52PM (#12163212)
CouchDB supports writing views in Erlang, if you prefer that. It's also faster than Javascript, although it changes some of the ordering semantics of the resulting views.

I decided to write my views[1] in Parenscript[2]. Might not be for everybody, but it makes them fit a lot better in the rest of the application.

[1] https://github.com/cicakhq/potato/blob/72e162a95332e8979d865...

[2] https://common-lisp.net/project/parenscript/

Re:The Road to CouchDB 2.0 by refrigerator on Monday July 25, 2016 @01:27PM (#12160133)
We've been using a self-hosted CouchDB 1.6.x instance on AWS, and actually a few days ago decided to try hosting the pre-RC version of 2.0. What are the benefits of using a hosted service like Cloudant over self-hosting?
Re:The Road to CouchDB 2.0 by noinsight on Monday July 25, 2016 @01:31PM (#12160156)
Exciting news, I just started using CouchDB in a new project and it works really well.

Is the new Fauxton interface included? The old GUI feels more like a proof of concept than an actual user interface. Fauxton would be appreciated.

Re:The Road to CouchDB 2.0 by refrigerator on Monday July 25, 2016 @01:37PM (#12160189)
yeah, Fauxton comes included in 2.0 (and it's really good!)
Re:The Road to CouchDB 2.0 by dahjelle on Monday July 25, 2016 @11:47AM (#12159444)
If I recall correctly, built-in clustering and the new Mango query language are the big new features. Are there others?
Re:The Road to CouchDB 2.0 by gwbas1c on Monday July 25, 2016 @11:16AM (#12159231)
I thought CouchDB was abandoned years ago?
Re:The Road to CouchDB 2.0 by dahjelle on Monday July 25, 2016 @11:45AM (#12159435)
Perhaps you are thinking of when Damien Katz (the original author of CouchDB) left the CouchDB project for CouchBase [1] (from which he has also since moved on [2])?

[1] http://damienkatz.net/2012/01/the_future_of_couchdb.html

[2] http://damienkatz.net/2013/09/human_after_all.html

Re:The Road to CouchDB 2.0 by Xylakant on Monday July 25, 2016 @11:30AM (#12159323)
it's been alive and kicking all the time with various interesting implementations that can sync back to couch, for example pouchdb for browsers and/or mobile websites: https://pouchdb.com/
Re:The Road to CouchDB 2.0 by mwambua on Monday July 25, 2016 @11:42AM (#12159406)
Thanks for the link. PouchDB seems to be a great example of an app that inherently works better with CouchDB/Cloudant than it would with MongoDB.
Re:The Road to CouchDB 2.0 by Xylakant on Monday July 25, 2016 @11:46AM (#12159438)
absolutely. I know some projects that implemented a mobile app with offline/sync capability using the couch/pouch combination. I haven't participated personally but from what the colleagues tell me it's working pretty well. (for all values of well that you can have when it comes to offline/sync. it's a tough problem.)
Re:The Road to CouchDB 2.0 by HodGreeley on Monday July 25, 2016 @05:31PM (#12161751)
You can take a look at Couchbase Mobile for native client offline+sync capabilities, too. PouchDB integrates with Couchbase Sync Gateway, so the combo is versatile.
Re:The Road to CouchDB 2.0 by s_kilk on Monday July 25, 2016 @02:38PM (#12160614)
I got the same impression when I started looking at CouchDB in January this year. Seemed like it had been ages since the last release, and very little activity.

Looks like they've just been busy for the past while working on this merge and (eventual) release of 2.0, will need to take another look.