3 ms·

I don't quite get pouchdb. Do you need to store multiple revisions of the same document in a browser database? Locks/transactions seem like a better approach he

I don't quite get pouchdb. Do you need to store multiple revisions of the same document in a browser database? Locks/transactions seem like a better approach here for writing to data client side.

brightball 8y ago
The main point is to sync server side data to a client side database, smoothly, so that the application can continue to function offline and then resync once the connection is re-established. Couch has always been good at this use case where systems on both ends may have changed in the disconnect time.
- HumanDrivenDev 8y ago
  but you could store Ids and revisions on any key/value store on the client. Why does the client need pouchdbs multiple revisions?
- jinjin2 8y ago
  Realm looks like a much more modern solution to that problem.
  - brightball 8y ago
    Not familiar with Realm
daleharvey 8y ago
Not entirely sure what you misunderstand, PouchDB stores multiple revisions because thats how CouchDB's sync protocol works, the point of PouchDB was to match CouchDB semantics. PouchDB (as CouchDB) provides options to control how much you track (revs_limit, auto_compaction) and there are improvements we could do to handle tracking less information better We use transactions under the hood actually writing data to indexeddb
- HumanDrivenDev 8y ago
  I mean I both get it, and don't get it. CouchDB is all about master-master, and pouchdb just brings that to the browser. But at the same time I don't understand why you'd want a 'master' at the edge of the network, or the overhead of multiple revisions when a users browser isn't going to have tones of concurrent connections. I fully admit I'm not very well-versed on databases or distributed computing, happy to have things clarified.
  - daleharvey 8y ago
    I had to make that distinction fairly early on wether PouchDB would be an edge client or a full node and I decided full node, tradeoffs either way but pros of being a full node: 1. Additional (p2p) use cases, honestly I dont use CouchDB much these days, I use express-pouchdb-server so I can embed pouchdb into my server easier than any other database, there is also pouchdb-server and p2p projects like Thali (http://thaliproject.org/ http://thaliproject.org/) 2. CouchDB existed, sync is super hard, writing an edge client would have meant designing it myself, writing a couchdb clone meant I needed to make a lot less decisions about how it worked while being very confident it would work, The test suite runs the same tests against pouchdb/couchdb to ensure compatibility (and replication via each configuration)

I don't quite get pouchdb. Do you need to store multiple revisions of the same document in a browser database? Locks/transactions seem like a better approach here for writing to data client side.

brightball 8y ago

The main point is to sync server side data to a client side database, smoothly, so that the application can continue to function offline and then resync once the connection is re-established. Couch has always been good at this use case where systems on both ends may have changed in the disconnect time.

HumanDrivenDev 8y ago
but you could store Ids and revisions on any key/value store on the client. Why does the client need pouchdbs multiple revisions?
jinjin2 8y ago
Realm looks like a much more modern solution to that problem.
- brightball 8y ago
  Not familiar with Realm

daleharvey 8y ago

Not entirely sure what you misunderstand, PouchDB stores multiple revisions because thats how CouchDB's sync protocol works, the point of PouchDB was to match CouchDB semantics. PouchDB (as CouchDB) provides options to control how much you track (revs_limit, auto_compaction) and there are improvements we could do to handle tracking less information better We use transactions under the hood actually writing data to indexeddb

HumanDrivenDev 8y ago
I mean I both get it, and don't get it. CouchDB is all about master-master, and pouchdb just brings that to the browser. But at the same time I don't understand why you'd want a 'master' at the edge of the network, or the overhead of multiple revisions when a users browser isn't going to have tones of concurrent connections. I fully admit I'm not very well-versed on databases or distributed computing, happy to have things clarified.
- daleharvey 8y ago
  I had to make that distinction fairly early on wether PouchDB would be an edge client or a full node and I decided full node, tradeoffs either way but pros of being a full node: 1. Additional (p2p) use cases, honestly I dont use CouchDB much these days, I use express-pouchdb-server so I can embed pouchdb into my server easier than any other database, there is also pouchdb-server and p2p projects like Thali (http://thaliproject.org/ http://thaliproject.org/) 2. CouchDB existed, sync is super hard, writing an edge client would have meant designing it myself, writing a couchdb clone meant I needed to make a lot less decisions about how it worked while being very confident it would work, The test suite runs the same tests against pouchdb/couchdb to ensure compatibility (and replication via each configuration)