Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is probably the biggest misunderstanding of couchdb, imo. The versioning system in couchdb is only there to make the seamless replication possible. There's no guarantee that previous versions will exist at a future time, like in git.

Where couchdb has some immense possibilities is in distributed applications, not only server side, but also mobile phones and browsers. Since you can write and contain an entire webapp inside of couchdb, you can technically replicate the entire app to your mobile phone, and it'd work offline or online. And if you need your app on another platform--as long as it has couchdb, you can just replicate it there.

I never see this mentioned in any overviews of comparison for couchdb.

The sticking point right now, though, is that couchdb isn't on very many mobile platforms. There has only been experiments with writing couchdb on top of HTML5's localStore, and jChris et al are working on Couchdb for android.



"The versioning system in couchdb is only there.."

CouchDB does not version, period.


The "versioning" is really just there to support their optimistic concurrency model, if I recall. The idea is that you know you need to retry your operation if the version hash of the file has gone up since you last read the data and thus you know your local file is out of date.

As I recall, the id field is just a string. It's just common to let it do the automatic "#-hash" representation.

It's been a while since I played with CouchDB though, so I could be off.


You are correct.


I didn't mention that (it does not really matter when choosing one right now), but I too consider that one of the most exciting explorations in this area!

Keep up the good work!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: