[
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)
