couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregor Martynus <gre...@martynus.net>
Subject Re: per-user databases & collaboration problem
Date Tue, 22 May 2012 17:18:21 GMT
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 <gregor@martynus.net (mailto:gregor@martynus.net)>
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  


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message