Hi Gregor, I admit I never had that problem, but I wouldn't allow Sarah to delete the document from Joe. Instead, I would create a blacklist document in Sarah's database in which she is allowed to add and delete Joe. If Joe is in the blacklist, then Sarah's would still have Joe's document, but the document would not be shown to Sarah. Once Sarah is changing her mind, she can delete Joe from her blacklist and, consequently, she can resume sharing and viewing Joe's docs.
Another option would be the reversed replication in which Sarah can add a certain field (e.g., key: Sarah, value: blacklisted) in Joe's document, so, the revisions in both databases to be at the same value. I don't know if these options have any value for you, but this is what I could think of to avoid the document conflict you mentioned. I hope it will give you at least an idea how to go around the problem. CGS On Tue, May 22, 2012 at 5:19 PM, Gregor Martynus <[email protected]>wrote: > Hey everyone, > > Imagine the following setup: 3 databases with 2 cont. replications: > > "user/joe" > || > || cont. replication (filtered) > || > \/ > "shared/123" > || > || cont. replication > || > \/ > "user/sarah" > > Joe (user/joe) is sharing a list of documents with an extra database > (shared/123) and a filtered replication. Sarah > (user/sarah) subscribed to the Joe's shared documents with another cont. > replication. > > So far, so awesome. > > And now the Problem: > > 1. Sarah deletes Joe's documents and stops the replication. > 2. Sarah changes her mind, she wants to have the documets back again > 3. it doesn't work, because new revisions have been added for each deleted > document, the shared documents do not get replicated because of the > conflicts. > > And here I am, and don't see a "couch way" to solve this problem. Neither > do I see a simple workaround. > > Is there anything you can think of, to solve or work around this problem? > Or is this kind of "sharing" between user databases broken by design? > > -- > Gregor > > > >
