Thanks again!
I've a question regarding the drawbacks you mentioned: isn't this a non-issue
when I use the _replicator database?
Let's say I've another cont. replication:
"shared/other"
||
|| cont. replication ("_replicator/other_sarah")
||
\/
"user/sarah"
When I delete "user/sarah", the replication doc will be set to status: "error".
As far as I know, there will be several attempts with growing timeouts to
restart the replication.
So after I recreate "user/sarah" from its earlier copy, the cont. replication
should be able to get back to a "triggered" status by itself, no? And the docs
/ revisions that got lost because of the double copy procedure will be
recreated by the replications as well, is that correct?
--
Gregor Martynus
On Tuesday, 22. May 2012 at 19:02, CGS wrote:
> 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 <[email protected]
> (mailto:[email protected])>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 <[email protected]
> > > (mailto:[email protected])(mailto:
> > [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
> > > >
> > >
> >
> >
>
>
>
