CODEWITHSUNDEEP
javascriptnode.jsnosqlcouchdbpouchdb
elkebirmed
elkebirmed

Reputation: 2347

Sync multiple PouchDB databases to one CouchDB database

In PouchDB Documentation I found that sync is between local database and the remote CouchDB database. I'm trying to build a native application that have a local database for every user (many databases) and sync to one remote database:

Let's say that user 01 syncs to the remote database, then user 02 syncs to it too. I think it'll override the data of the first user. This is what I want:

// Default
user1 = ['data']
user2 = ['data']
remote = [user1 or user2]

// what i want
user1 = ['data']
user2 = ['data']
remote = [user1, user2, ....etc]

Upvotes: 2

Views: 1249

Answers (1)

Dominic Barnes
Dominic Barnes

Reputation: 28429

Replication relies on the sequence of the databases being synced. Thus, you only "overwrite" data when their _id values will clobber one another. However, I suspect the next issue you'll need to contend with is keeping user data separate.

If you replicate all your users into a single database, all your users will also receive every other users' data as well when they replicate back out of that single database. I'm not sure what your use-case is, but that isn't generally how apps are structured. If you want to use a single database like this, you'll need to include some sort of tagging to your documents and use Filtered Replication.

To keep your data segmented by user, you'll need to be diligent in using this parameter every time you sync. However, your database is probably exposed to the public internet if you're syncing them, and the lack of document-level controls means your savy users will be able to see everyone else's data anyways.

My recommendation here is to give each user their own database, rather than replicating everything into a single hub database. With CouchDB 2.x, you have access to couch_peruser, which gives each registered user their own database automatically. (this will require registering your users with CouchDB as well, but honestly it's the best for security in a publicly-exposed server anyways)

Upvotes: 3

Related Questions