Thanks Benoît, that's a really interesting approach that I haven't thought of yet. Unfortunately it doesn't work for my particular case.
-- Gregor Martynus On Tuesday, 22. May 2012 at 19:10, Benoit Chesneau wrote: > On Tue, May 22, 2012 at 5:19 PM, Gregor Martynus <[email protected] > (mailto:[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 > > > > Maybe a solution would be to save each version of the document as a > document. Then Sarah would continue to get each changes even if she > stopped to follow Joe for a time. In short don't change a document but > create a new one each time you make a change in. > > - benoit
