couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Ramage (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1906) Removing DB referenced by _replicator should halt replication / remove doc
Date Mon, 02 Dec 2013 23:16:35 GMT


Ryan Ramage commented on COUCHDB-1906:

Just a note, I was bit by this with create_target: true. Some edited for readability irc logs:

ryan_ramage: ok, noticed a weird one today…just checking if my head is on right…I created
a db with a _replicator doc ends up looking like this:
 then I delete the db, and within seconds, the database is recreated, with the ddoc in it
[3:56pm] ryan_ramage: I assume the replicator is not respecting my DELETE     (on 1.5)
[3:57pm] rnewson: ryan_ramage:  "create_target": true,
[3:57pm] ryan_ramage: yeah
[3:57pm] rnewson: ryan_ramage: the replicator is doing what you asked it to do.
[3:58pm] ryan_ramage: recreate_target: false 
[3:58pm] ryan_ramage: rnewson: I get that, but something does not feel right about it
[3:59pm] rnewson: really? it makes perfect sense to me.
[3:59pm] wickedgrey: yeah, this is basically the same issue that i reported a month or so
ago, regarding replications not stopping after deleting the DB (mine was removing the source,
not the target)
[3:59pm] ryan_ramage: wickedgrey: do you have a jira num I can look at the discussion?
[3:59pm] wickedgrey: sure, one moment
[4:00pm] rnewson: you've asked couchdb to persistently, relentlessly and continuously replicate
source to target, creating the target if it's missing. If the target is deleted, the replication
job crashes, is restarted, recreates, carries on.
[4:01pm] rnewson: you need to stop the thing that creates the db if you want the db to not
be created.
[4:01pm] wickedgrey:
[4:01pm] kandinski: or have a 'deleted' property in the document, and use that instead of
[4:03pm] ryan_ramage: rnewson: will have to ponder. seems to violate
[4:03pm] wickedgrey: rnewson: perhaps i should be stating this in the ticket, but i maintain
that it's surprising behavior.
[4:03pm] kandinski: you should delete the replication document first, then the database
[4:03pm] rnewson: it would be more surprising for the replicator to be that tightly coupled
to quite separate things like remote databases.

[4:05pm] wickedgrey: i think that the behavior gets a lot more obvious when the implementation
is known.  to a pure-user of the system, it's not obvious that the current behavior is going
to be what happens.
[4:06pm] rnewson: the state that the server is in when you delete the database and don't want
to recreate it is is the same as when the target doesn't exist and you do want it to create
[4:06pm] ryan_ramage: I expect create_target to fire once and only once
[4:06pm] rnewson: the lesson is to avoid create_target:true
[4:06pm] ryan_ramage: or maybe depreciate create_target
[4:07pm] wickedgrey: ryan_ramage: note that you get a similar error condition when you delete
the source DB (though the symptom is lots of errors in the couch.log, rather than recreated
[4:08pm] wickedgrey: the problem isn't inherently tied to create_target
[4:08pm] ryan_ramage: yes I see
[4:08pm] rnewson: ryan_ramage: remove a feature just for you? I don't think so. 
[4:10pm] ryan_ramage: kandinski: yeah, I have lots of options for ways to solve, just this
is a strange intersection of a couple of the couch apis
[4:10pm] ryan_ramage: and the idea of a pulled out replicator puts a +1 in rnewson camp
[4:10pm] ryan_ramage: as they are separate things

> Removing DB referenced by _replicator should halt replication / remove doc 
> ---------------------------------------------------------------------------
>                 Key: COUCHDB-1906
>                 URL:
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Replication
>            Reporter: Eli Stevens
> Removing a DB that is involved in replication via the _replicator DB should remove the
corresponding _replicator document.
> Currently, couch.log includes errors when the DB is removed.
> My perspective is that replication is "just a feature of a DB" in the same way that attachments
are; one doesn't need to separately remove attachments after deleting a DB, and similarly
I've already expressed that I'm no longer interested the DB, its attachments, its replications,
etc. by deleting it.

This message was sent by Atlassian JIRA

View raw message