LALazare·Apr 9, 2013
CouchDB's replication is nifty because, in a sense, there is no replication. Or rather, not in the sense that MySQL or MongoDB might talk about replication as a separate process or separate protocol.
I spent a while typing of descriptions of how it works, but honestly I think you're best served by these two answers:
http://stackoverflow.com/a/4766398/17086
https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replicatio...
It's not magic, no. It does, however, work a lot like git (a good thing!). The biggest downside is that it pushes some of the work to the client; you really do have to figure out how to handle conflicts in some cases. For example, if you edit the same field on the same doc in different ways on two different clients and then try to sync, there is no automatic way to resolve that other than throwing one edit away (which y
Read the rest
ou can totally do if that works for your problem space). Luckily, that's not a very common situation. :) And, again, how else are you going to solve something like that? It all comes back to the CAP theorem - you can have at most two of consistency, availability, and partition tolerance. Rich mobile apps can work around a lack of consistency if they must, but a lack of availability and partition tolerance undermines the "mobile" part; for some projects (like mine) that is unacceptable.
As for TouchDB, if memory serves it actually was running an erlang VM at one point, but has long since been rewritten into native Objective C (for the iOS version) and Java (for the Android version). The PouchDB version is written purely in Javascript. Again, all that matters in the end is that it speaks the protocol. As @caolan put it, CouchDB is not a database:
http://caolanmcmahon.com/posts/couchdb_is_not_a_database/
It's a protocol. :)