[ https://issues.apache.org/jira/browse/COUCHDB-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837063#comment-13837063 ]
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: https://gist.github.com/ryanramage/7760588 then I delete the db, and within seconds, the database is recreated, with the ddoc in it again [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: https://issues.apache.org/jira/browse/COUCHDB-1906 [4:01pm] kandinski: or have a 'deleted' property in the document, and use that instead of DELETE [4:03pm] ryan_ramage: rnewson: will have to ponder. seems to violate http://en.wikipedia.org/wiki/Principle_of_least_astonishment [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 it. [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 DBs) [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: https://issues.apache.org/jira/browse/COUCHDB-1906 > 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 (v6.1#6144)