Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of cgsmcmlxxv@gmail.com
 designates 209.85.214.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D801CE431785442C9EE63DDA0B628530@martynus.net>
References: <5CE5E627D3974CE18853BFCA6942C520@martynus.net>
	<CAKrexVLQRZ-Y+f37mJC2ZWYrMMKKpZTyk+q07V9-p_pC+6YCOg@mail.gmail.com>
	<D801CE431785442C9EE63DDA0B628530@martynus.net>
Date: Tue, 22 May 2012 19:02:28 +0200
Message-ID: 
 <CAKrexVLeZn0vGXGCcfTkeCk-vo5Cs3qeW=oBkZDgjeybs+P0Jw@mail.gmail.com>
Subject: Re: per-user databases & collaboration problem
From: CGS <cgsmcmlxxv@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=f46d04448163cd607a04c0a2fb0d

--f46d04448163cd607a04c0a2fb0d
Content-Type: text/plain; charset=ISO-8859-1

That's also an option. If you want to pursue that idea, I would replicate
the Sarah's database filtering Joe's documents and I would switch Sarah's
access to the new database. But there are few drawbacks here (you need to
redirect all the continuous replications from the other users while you
replicate the same docs from Sarah's database if not filtered and so on).
About how expensive this method is, yes, it depends on how large the
database is, but I don't think this is the worst inconvenient.

Nevertheless, if you plan carefully this method, it is a valid option.

CGS


On Tue, May 22, 2012 at 6:43 PM, Gregor Martynus <gregor@martynus.net>wrote:

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

--f46d04448163cd607a04c0a2fb0d--