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:11:07 GMT
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 <gregor@martynus.net (mailto: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)(mailto:
> > 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
> > > > 
> > > 
> > 
> > 
> 
> 
> 



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