incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CGS <>
Subject Re: per-user databases & collaboration problem
Date Tue, 22 May 2012 16:18:51 GMT
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.


On Tue, May 22, 2012 at 5:19 PM, Gregor Martynus <>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

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