Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 gregor@martynus.net does not designate 209.85.214.52 as permitted sender)
Date: Tue, 22 May 2012 18:43:32 +0200
From: Gregor Martynus <gregor@martynus.net>
To: user@couchdb.apache.org
Message-ID: <D801CE431785442C9EE63DDA0B628530@martynus.net>
In-Reply-To: 
 <CAKrexVLQRZ-Y+f37mJC2ZWYrMMKKpZTyk+q07V9-p_pC+6YCOg@mail.gmail.com>
References: <5CE5E627D3974CE18853BFCA6942C520@martynus.net>
 <CAKrexVLQRZ-Y+f37mJC2ZWYrMMKKpZTyk+q07V9-p_pC+6YCOg@mail.gmail.com>
Subject: Re: per-user databases & collaboration problem
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="4fbbc234_4c4fff5b_14d"

--4fbbc234_4c4fff5b_14d
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks CGS! I'll think deeper about the two options.

Actually, I think there is one radical "solution" to the problem

1. Create a copy of Sarah's database, filtering out all deleted documents
2. Delete Sarah's database
3. Recreate Sarah's database using the copy from 2.

I wonder how expensive such an operation would be? What do you think?
Maybe it would be a feasible way, as it would be "only" a user database, with maybe a few thousand documents.


-- 
Gregor Martynus


On Tuesday, 22. May 2012 at 18:18, CGS wrote:

> 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 <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
> > 
> 
> 
> 


--4fbbc234_4c4fff5b_14d--