How to selectively replicate private and public parts of a CouchDB database?

We are exploring using CouchDB / CouchCocoa to replicate data to our mobile app.

Our system has a large number of users. Part of the database is private to each user - for example, their tasks. This way I was able to replicate without any problems using filtered replication .

The catch here ... The database also includes general information, only a few of which are relevant to this user. How can I selectively copy this general information? For example, a user's task can link to certain shared documents. Is there a way to ensure that these documents are included in replication without including all shared documents?

From the documentation it seems that adding doc_ids

to replication (or adding another replication with these doc IDs) might be one solution. Has anyone tried this? Are there other solutions?

EDIT: Given the number of users, it seems impractical to tag every shared document by all users who use it, but perhaps this is the only way to do it?

+3


source to share


1 answer


The final solution mainly depends on the structure of your documents, but I currently see two use cases:

  • How do you store everything in one database, maybe you have some fields that need to be recognized, this document is shared or the document is confidential, right? Example:

    owner: "Mike"

    members: [] // if no one is mentioned, the document looks like closed (?)

    So, all you need is a filter that only processes private documents and only general ones: by tags, number of members, links, or somehow.

    Also, if you need to replicate some documents for a specific user only (for example, just for Mike), you need a special view to handle all of those documents and, yes, use replication using document IDs, but that would not be an atomic request: to process of these steps, you will need a script service. If shared documents are defined by referencing them, then the only solution is the same: some service script, view that generated link tree and replicate with doc._id.

  • Review your architecture. Having a custom use case for CouchDB in the user database and follows data separation and isolation. This way you can create for each user database that will be closed only for that user. For shared documents, you can create additional databases by playing around with the security settings database items. Each "shared" database will only handle a certain number of members by name or by group, so there can be no data leaks unless it was a CouchDB bug (:

    This approach looks too strange at first glance, but all you need is to create some control script that will handle creating and publishing the database, replication will be as easy as possible, and user data will be safe.



PS I assumed that the "sharing" operation makes the document visible not to everyone, but to a certain set of users. If I was wrong, and "shared" state means "public" state than p2. it will be simpler: N user databases + 1 public.

+2


source







All Articles