6 ms·

CouchDB ships 1.2.0, Windows packages, new website

92 points by nslater 15y ago

iamwil 15y ago
Does anyone know if they have CouchDB on iOS, Android, or even on the browser? Last I checked, they didn't, and only had experimental builds on each. To me, that'd be a much more compelling reason to use CouchDB, since syncing between server and client is a pain, and having CouchDB on both servers and client would make development life much easier for me. If not, then publish the replication protocol. I tried looking for it once, and only found scant information on the mailing lists and documentation.
- shadowmatter 15y ago
  I found the following two documents on the replication protocol: http://www.dataprotocols.org/en/latest/couchdb_replication.html http://www.dataprotocols.org/en/latest/couchdb_replication.h... https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replication-Algorithm https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replicatio... From the end of http://wiki.apache.org/couchdb/Replication http://wiki.apache.org/couchdb/Replication
  - tilgovi 15y ago
    Nice! I didn't realize so much had been done on dataprotocols.org yet!
- daleharvey 15y ago
  Couchbase mobile is the CouchDB server running on android and ios, it works and is a released product by Couchbase, they are also planning to supercede these with native implementations (TouchDB for iOS and Android) While building TouchDB Jens documented the replication protocol here: https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replication-Algorithm https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replicatio... I am working on (actually am right now) the in browser implementation of CouchDB called PouchDB (https://github.com/mikeal/pouchdb https://github.com/mikeal/pouchdb) it is nearing a beta release.
  - robterrell 15y ago
    Hooray, been hacking on the upstream PouchDB myself, glad to hear you've got it far along!
    - daleharvey 15y ago
      Awesome, got a url? the more working on this the merrier :)
- tilgovi 15y ago
  PouchDB is ready for some testing and play. Dale Harvey has put a lot of work into it recently: https://github.com/daleharvey/pouchdb https://github.com/daleharvey/pouchdb I'll see what I can do about getting a good publication of the replication protocol. People have been asking about it for a long time. I've only come to fully grok it late last year when I tried to write PouchDB and I talked through it with Dale when he picked up my slack. We can probably get that together. A great first example that I'd love to see is using PouchDB to implement Backbone.Sync for a Backbone app.
  - tftf 15y ago
    I just wrote a Backbone Sync Adapter for PouchDB: https://github.com/jo/backbone-pouchdb https://github.com/jo/backbone-pouchdb Its very basic but has a working Todo example.
- jchrisa 15y ago
  If you are interested in Couch-like magic in the mobile context, we've got an active mailing list for TouchDB and other mobile projects here: https://groups.google.com/forum/#!forum/mobile-couchbase https://groups.google.com/forum/#!forum/mobile-couchbase
- nupark2 15y ago
  The problems on mobile are so incredibly different than server, I don't see that CouchDB would be useful client-side. The focus client-side is on speed, battery-life, ease of programming, and perhaps most of all, maintaining separation of concerns between the server-side data model and the client data model. The server must be free to evolve independently of the client, and many remote clients will run legacy versions of your software for extended periods of time. Moreover, rarely is data distribution sufficient to model high-level interactions between client and server, which is more likely to introduce bugs, complexity, and significantly detract from the long-term maintainability of the client/server protocol. The end result is that you don't particularly benefit from CouchDB client-side, and especially not replication -- you need a well-defined supportable network model.
  - jchrisa 15y ago
    Speed, battery-life, ease of programming are 3 of the main reasons we are motivated to build a Couch-compatible storage and sync layer on the device. If you have an intelligent sync solution, you can use significantly less radio time to present the same features. This saves battery life, and gives a better user experience as folks aren't waiting for hundreds of milliseconds for request and response to propagate across unreliable mobile networks. As far as the maintainability concerns, it's an interesting point. There are certainly apps which may want to sacrifice the ease of use and performance advantages of having sync done for you, because they have specialized data sharing requirements. But for a whole lot of apps the benefits of sync far outweigh the contraints of having the same data model on the client and server. Some example use cases where sync can simplify programming (or even make a class of apps possible which would be much harder without it): point-of-sale, retail, medical records (doctor with an iPad and limited wifi), military (need that data no matter what). Here's a pdf of the slides I presented yesterday at Chicago's WindyCityGo conference: http://dl.dropbox.com/u/14074521/syncpoint-windycity-small.pdf http://dl.dropbox.com/u/14074521/syncpoint-windycity-small.p...
    - nupark2 15y ago
      > Speed, battery-life, ease of programming are 3 of the main reasons we are motivated to build a Couch-compatible storage and sync layer on the device. If you have an intelligent sync solution, you can use significantly less radio time to present the same features. You're just moving the costs around, and likely transmitting far more data than needs be sent. In addition, you're front-loading the transmission of data that users don't need right now. Having built many network-facing mobile applications with exceedingly large user bases, I'm unconvinced. The maintenance complexity, the excess transmission of data, issues of data consistency over time, the lack of integration with client-side business rules without considerable investment in code that significantly replaces the sync logic. I think that the reality of the situation is that in the rare cases you need offline, fully synchronized data, it's not particularly difficult to just download what you need as an atomic unit and save it. The majority of the time, however, on-demand request handling is more efficient, well-defined, and maintainable.
JulianMorrison 15y ago
What's new?
- janl 15y ago
  We summed it up here: https://blogs.apache.org/couchdb/entry/apache_couchdb_1_2_0 https://blogs.apache.org/couchdb/entry/apache_couchdb_1_2_0
- rdtsc 15y ago
  http://www.apache.org/dist/couchdb/notes/1.2.0/apache-couchdb-1.2.0.html http://www.apache.org/dist/couchdb/notes/1.2.0/apache-couchd... Highlights I like: * Speed improvements (native JSON parser) * Autocompaction (no need to create daemons to compact db periodically anymore). * Snappy compression enabled by default (should reduce db sizes and perhaps provide some speed improvements) * Added built-in changes feed filter _view. This basically means you can use your view to filter your changes feed.
  - justauser 15y ago
    Does anyone know what language the previous JSON parser was written in...Erlang?
    - janl 15y ago
      Yup. We used mochijson2.
pdhborges 15y ago
Another site with a fixed header taking a large chunk of the screen. Seriously, what's wrong with you designers!!??
- pooriaazimi 15y ago
  I specially hate it on blogs, or other pages that have a long content. I like to press 'space' to move to the next page[1], but with these fixed-header mania lately, I have to press space and then up-arrow a couple times... This trend has to stop NOW. Use frames(!) if you have to... -- [1] when Safari Reader fails to capture the main content
rdtsc 15y ago
It's looking like a great release: auto-compaction, compression, speed improvements, security stuff. Can't wait to try it.
justauser 15y ago
Is Damien Katz still involved or completely moved onto the Membase...Couchio...Couchbase entity now? I like the layout and high contrast of the new site. My only comment is perhaps a header link to the "Quick Links" at the footer. I tend to want to look at documentation quite a bit and the scroll to the footer was not intuitive.
- janl 15y ago
  Damien works full-time on Couchbase technology now. Some of which is still applicable to Apache CouchDB and is and will be contributed back to the project, but he is no longer directly involved. The rest of the team more than makes up for it though :)
  - justauser 15y ago
    Thanks. Reading through the changelog, you all have done some tremendous work.
    - janl 15y ago
      Appreciated! :)
  - js4all 15y ago
    I would like to thank you and those of the original team who are still being involved for your support of the Apache fork. Many thanks. When I read Damien's note back in January, I was prepared to never see updates to CouchDB.
    - nslater 15y ago
      Just to clarify, the Couchbase product is a backwards-incompatible fork of Apache CouchDB. Apache CouchDB remains the original CouchDB. It is where most of the developers are, and where most of the community is. The one and only! HUZZAH! ;)
pertorstensson 15y ago
Any package for Mac in the works?
- mark_l_watson 15y ago
  It builds easily from source. Use homebrew to get the dependencies. Or, wait a while and then do "brew install couchdb" after the homebrew build scripts are updated.
  - daleharvey 15y ago
    That being said, there are still mac builds in the works
    - kika 15y ago
      Couchbase single server for Mac had a nice menubar widget, which allowed for control of the couchdb process, had shortcuts to Futon and logs, etc. Does anyone know where the sources are? I'm using build-couch scripts now and want to reintroduce this widget back there.
      - daleharvey 15y ago
        https://github.com/couchbase/couchdbx-app https://github.com/couchbase/couchdbx-app
        kika 15y ago
        awesome, thanks!
peter_l_downs 15y ago
Still no C API/Library/Tutorial. I just sent an email to the dev list, but for anyone interested: check out pouch [0], a library I wrote. [0] https://github.com/peterldowns/pouch https://github.com/peterldowns/pouch
rb2k_ 15y ago
YAY! Seeing as this included snappy compression the last time I checked, I might be able to replace the "couchbase single server" with the couchdb 1.2 release. Anybody tried that upgrade?
- rb2k_ 15y ago
  update: worked fine
rmccue 15y ago
I've looked into using this before and couldn't work out why I'd want to use it over alternatives, or how it stored data. I think the new website is fantastic, as I now know all of this and more just from a quick glace. Great work.
- rogerbinns 15y ago
  The one thing CouchDB does really well is multi-master replication. Any server can be in any state and replicate with any others. It works somewhat analogously to a flood fill. Contrast with other databases where you have to nominate master servers and communicate with them. I gave up on CouchDB two years ago. Partly it was a poor experience with the community, but mostly technical issues. Writing is done to append only journals. This means not only the added/changed data is written but also all changed btree nodes. I was starting with around 2GB of JSON data (10 million documents). With CouchDB it would turn into 43GB on disk (including views/indices). With tuning, tweaks and compaction I was able to get it to half of that, but it was still a massive explosion of data size. I tried MongoDB with the same data and ended up with just over 4GB consumed on disk. In addition my data load time was 6 minutes compared to 75 minutes for CouchDB. I was even experiencing unindexed queries in MongoDB being faster than indexed ones in CouchDB! I'm sure CouchDB has improved a bit since then, but I don't think the implementation can do much better especially at the data sizes I was doing. (Personally I think that is a rather small amount of data, one of the CouchDB developers called a million documents large!)
- lvillani 15y ago
  > I think the new website is fantastic, as I now know all of this and more just from a quick glace. Great work. I noticed that it is almost identical to Apache Cordova's [1]. Is there an ongoing effort to bring a consistent look to all Apache projects websites? [1]: https://incubator.apache.org/cordova/ https://incubator.apache.org/cordova/
  - Kiall 15y ago
    I noticed in the HTML source that they credit Cordova: > Thanks to Yohei Shimomae and the Apache Cordova team for the original design....
antonios 15y ago
I believe CouchDB is starting to feel a much more mature and polished product nowdays. Kudos to the developers for their hard work.
- drudru11 15y ago
  Yeah, totally agree. Great work couchdb team on this release!
js4all 15y ago
Great news. CouchDB is still living. The change log is impressive. However, it is worth to mention that the database file format has changed. Once on 1.2 your files get upgraded to the new format. There is no going back.
kinleyd 15y ago
I've been dabbling with CouchDB for a while now, and have been keenly following developments with CouchBase. It's looking good on both fronts. :)

92 points by nslater 15y ago

Does anyone know if they have CouchDB on iOS, Android, or even on the browser? Last I checked, they didn't, and only had experimental builds on each. To me, that'd be a much more compelling reason to use CouchDB, since syncing between server and client is a pain, and having CouchDB on both servers and client would make development life much easier for me. If not, then publish the replication protocol. I tried looking for it once, and only found scant information on the mailing lists and documentation.

shadowmatter 15y ago
I found the following two documents on the replication protocol: http://www.dataprotocols.org/en/latest/couchdb_replication.html http://www.dataprotocols.org/en/latest/couchdb_replication.h... https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replication-Algorithm https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replicatio... From the end of http://wiki.apache.org/couchdb/Replication http://wiki.apache.org/couchdb/Replication
- tilgovi 15y ago
  Nice! I didn't realize so much had been done on dataprotocols.org yet!
daleharvey 15y ago
Couchbase mobile is the CouchDB server running on android and ios, it works and is a released product by Couchbase, they are also planning to supercede these with native implementations (TouchDB for iOS and Android) While building TouchDB Jens documented the replication protocol here: https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replication-Algorithm https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replicatio... I am working on (actually am right now) the in browser implementation of CouchDB called PouchDB (https://github.com/mikeal/pouchdb https://github.com/mikeal/pouchdb) it is nearing a beta release.
- robterrell 15y ago
  Hooray, been hacking on the upstream PouchDB myself, glad to hear you've got it far along!
  - daleharvey 15y ago
    Awesome, got a url? the more working on this the merrier :)
tilgovi 15y ago
PouchDB is ready for some testing and play. Dale Harvey has put a lot of work into it recently: https://github.com/daleharvey/pouchdb https://github.com/daleharvey/pouchdb I'll see what I can do about getting a good publication of the replication protocol. People have been asking about it for a long time. I've only come to fully grok it late last year when I tried to write PouchDB and I talked through it with Dale when he picked up my slack. We can probably get that together. A great first example that I'd love to see is using PouchDB to implement Backbone.Sync for a Backbone app.
- tftf 15y ago
  I just wrote a Backbone Sync Adapter for PouchDB: https://github.com/jo/backbone-pouchdb https://github.com/jo/backbone-pouchdb Its very basic but has a working Todo example.
jchrisa 15y ago
If you are interested in Couch-like magic in the mobile context, we've got an active mailing list for TouchDB and other mobile projects here: https://groups.google.com/forum/#!forum/mobile-couchbase https://groups.google.com/forum/#!forum/mobile-couchbase
nupark2 15y ago
The problems on mobile are so incredibly different than server, I don't see that CouchDB would be useful client-side. The focus client-side is on speed, battery-life, ease of programming, and perhaps most of all, maintaining separation of concerns between the server-side data model and the client data model. The server must be free to evolve independently of the client, and many remote clients will run legacy versions of your software for extended periods of time. Moreover, rarely is data distribution sufficient to model high-level interactions between client and server, which is more likely to introduce bugs, complexity, and significantly detract from the long-term maintainability of the client/server protocol. The end result is that you don't particularly benefit from CouchDB client-side, and especially not replication -- you need a well-defined supportable network model.
- jchrisa 15y ago
  Speed, battery-life, ease of programming are 3 of the main reasons we are motivated to build a Couch-compatible storage and sync layer on the device. If you have an intelligent sync solution, you can use significantly less radio time to present the same features. This saves battery life, and gives a better user experience as folks aren't waiting for hundreds of milliseconds for request and response to propagate across unreliable mobile networks. As far as the maintainability concerns, it's an interesting point. There are certainly apps which may want to sacrifice the ease of use and performance advantages of having sync done for you, because they have specialized data sharing requirements. But for a whole lot of apps the benefits of sync far outweigh the contraints of having the same data model on the client and server. Some example use cases where sync can simplify programming (or even make a class of apps possible which would be much harder without it): point-of-sale, retail, medical records (doctor with an iPad and limited wifi), military (need that data no matter what). Here's a pdf of the slides I presented yesterday at Chicago's WindyCityGo conference: http://dl.dropbox.com/u/14074521/syncpoint-windycity-small.pdf http://dl.dropbox.com/u/14074521/syncpoint-windycity-small.p...
  - nupark2 15y ago
    > Speed, battery-life, ease of programming are 3 of the main reasons we are motivated to build a Couch-compatible storage and sync layer on the device. If you have an intelligent sync solution, you can use significantly less radio time to present the same features. You're just moving the costs around, and likely transmitting far more data than needs be sent. In addition, you're front-loading the transmission of data that users don't need right now. Having built many network-facing mobile applications with exceedingly large user bases, I'm unconvinced. The maintenance complexity, the excess transmission of data, issues of data consistency over time, the lack of integration with client-side business rules without considerable investment in code that significantly replaces the sync logic. I think that the reality of the situation is that in the rare cases you need offline, fully synchronized data, it's not particularly difficult to just download what you need as an atomic unit and save it. The majority of the time, however, on-demand request handling is more efficient, well-defined, and maintainable.

JulianMorrison 15y ago

What's new?

janl 15y ago
We summed it up here: https://blogs.apache.org/couchdb/entry/apache_couchdb_1_2_0 https://blogs.apache.org/couchdb/entry/apache_couchdb_1_2_0
rdtsc 15y ago
http://www.apache.org/dist/couchdb/notes/1.2.0/apache-couchdb-1.2.0.html http://www.apache.org/dist/couchdb/notes/1.2.0/apache-couchd... Highlights I like: * Speed improvements (native JSON parser) * Autocompaction (no need to create daemons to compact db periodically anymore). * Snappy compression enabled by default (should reduce db sizes and perhaps provide some speed improvements) * Added built-in changes feed filter _view. This basically means you can use your view to filter your changes feed.
- justauser 15y ago
  Does anyone know what language the previous JSON parser was written in...Erlang?
  - janl 15y ago
    Yup. We used mochijson2.

pdhborges 15y ago

Another site with a fixed header taking a large chunk of the screen. Seriously, what's wrong with you designers!!??

pooriaazimi 15y ago
I specially hate it on blogs, or other pages that have a long content. I like to press 'space' to move to the next page[1], but with these fixed-header mania lately, I have to press space and then up-arrow a couple times... This trend has to stop NOW. Use frames(!) if you have to... -- [1] when Safari Reader fails to capture the main content

rdtsc 15y ago

It's looking like a great release: auto-compaction, compression, speed improvements, security stuff. Can't wait to try it.

justauser 15y ago

Is Damien Katz still involved or completely moved onto the Membase...Couchio...Couchbase entity now? I like the layout and high contrast of the new site. My only comment is perhaps a header link to the "Quick Links" at the footer. I tend to want to look at documentation quite a bit and the scroll to the footer was not intuitive.

janl 15y ago
Damien works full-time on Couchbase technology now. Some of which is still applicable to Apache CouchDB and is and will be contributed back to the project, but he is no longer directly involved. The rest of the team more than makes up for it though :)
- justauser 15y ago
  Thanks. Reading through the changelog, you all have done some tremendous work.
  - janl 15y ago
    Appreciated! :)
- js4all 15y ago
  I would like to thank you and those of the original team who are still being involved for your support of the Apache fork. Many thanks. When I read Damien's note back in January, I was prepared to never see updates to CouchDB.
  - nslater 15y ago
    Just to clarify, the Couchbase product is a backwards-incompatible fork of Apache CouchDB. Apache CouchDB remains the original CouchDB. It is where most of the developers are, and where most of the community is. The one and only! HUZZAH! ;)

pertorstensson 15y ago

Any package for Mac in the works?

mark_l_watson 15y ago
It builds easily from source. Use homebrew to get the dependencies. Or, wait a while and then do "brew install couchdb" after the homebrew build scripts are updated.
- daleharvey 15y ago
  That being said, there are still mac builds in the works
  - kika 15y ago
    Couchbase single server for Mac had a nice menubar widget, which allowed for control of the couchdb process, had shortcuts to Futon and logs, etc. Does anyone know where the sources are? I'm using build-couch scripts now and want to reintroduce this widget back there.
    - daleharvey 15y ago
      https://github.com/couchbase/couchdbx-app https://github.com/couchbase/couchdbx-app
      - kika 15y ago
        awesome, thanks!

peter_l_downs 15y ago

Still no C API/Library/Tutorial. I just sent an email to the dev list, but for anyone interested: check out pouch [0], a library I wrote. [0] https://github.com/peterldowns/pouch https://github.com/peterldowns/pouch

rb2k_ 15y ago

YAY! Seeing as this included snappy compression the last time I checked, I might be able to replace the "couchbase single server" with the couchdb 1.2 release. Anybody tried that upgrade?

rb2k_ 15y ago
update: worked fine

rmccue 15y ago

I've looked into using this before and couldn't work out why I'd want to use it over alternatives, or how it stored data. I think the new website is fantastic, as I now know all of this and more just from a quick glace. Great work.

rogerbinns 15y ago
The one thing CouchDB does really well is multi-master replication. Any server can be in any state and replicate with any others. It works somewhat analogously to a flood fill. Contrast with other databases where you have to nominate master servers and communicate with them. I gave up on CouchDB two years ago. Partly it was a poor experience with the community, but mostly technical issues. Writing is done to append only journals. This means not only the added/changed data is written but also all changed btree nodes. I was starting with around 2GB of JSON data (10 million documents). With CouchDB it would turn into 43GB on disk (including views/indices). With tuning, tweaks and compaction I was able to get it to half of that, but it was still a massive explosion of data size. I tried MongoDB with the same data and ended up with just over 4GB consumed on disk. In addition my data load time was 6 minutes compared to 75 minutes for CouchDB. I was even experiencing unindexed queries in MongoDB being faster than indexed ones in CouchDB! I'm sure CouchDB has improved a bit since then, but I don't think the implementation can do much better especially at the data sizes I was doing. (Personally I think that is a rather small amount of data, one of the CouchDB developers called a million documents large!)
lvillani 15y ago
> I think the new website is fantastic, as I now know all of this and more just from a quick glace. Great work. I noticed that it is almost identical to Apache Cordova's [1]. Is there an ongoing effort to bring a consistent look to all Apache projects websites? [1]: https://incubator.apache.org/cordova/ https://incubator.apache.org/cordova/
- Kiall 15y ago
  I noticed in the HTML source that they credit Cordova: > Thanks to Yohei Shimomae and the Apache Cordova team for the original design....

antonios 15y ago

I believe CouchDB is starting to feel a much more mature and polished product nowdays. Kudos to the developers for their hard work.

drudru11 15y ago
Yeah, totally agree. Great work couchdb team on this release!

js4all 15y ago

Great news. CouchDB is still living. The change log is impressive. However, it is worth to mention that the database file format has changed. Once on 1.2 your files get upgraded to the new format. There is no going back.

kinleyd 15y ago

I've been dabbling with CouchDB for a while now, and have been keenly following developments with CouchBase. It's looking good on both fronts. :)