Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Mon, 2 Dec 2013 23:16:35 +0000 (UTC)
From: "Ryan Ramage (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12673297.1381434000080.57776.1386026195877@arcas>
In-Reply-To: <JIRA.12673297.1381434000080@arcas>
References: <JIRA.12673297.1381434000080@arcas>
Subject: [jira] [Commented] (COUCHDB-1906) Removing DB referenced by
 _replicator should halt replication / remove doc
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/COUCHDB-1906?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13=
837063#comment-13837063 ]=20

Ryan Ramage commented on COUCHDB-1906:
--------------------------------------

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

ryan_ramage: ok, noticed a weird one today=E2=80=A6just checking if my head=
 is on right=E2=80=A6I 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=20
[3:58pm] ryan_ramage: rnewson: I get that, but something does not feel righ=
t 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 co=
ntinuously replicate source to target, creating the target if it's missing.=
 If the target is deleted, the replication job crashes, is restarted, recre=
ates, carries on.
[4:01pm] rnewson: you need to stop the thing that creates the db if you wan=
t 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 t=
hat 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 ticke=
t, 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 obvio=
us that the current behavior is going to be what happens.
[4:06pm] rnewson: the state that the server is in when you delete the datab=
ase 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 conditi=
on when you delete the source DB (though the symptom is lots of errors in t=
he 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.=20
[4:10pm] ryan_ramage: kandinski: yeah, I have lots of options for ways to s=
olve, 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 do=
c=20
> -------------------------------------------------------------------------=
--
>
>                 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 shou=
ld 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 sam=
e way that attachments are; one doesn't need to separately remove attachmen=
ts after deleting a DB, and similarly I've already expressed that I'm no lo=
nger interested the DB, its attachments, its replications, etc. by deleting=
 it.


--
This message was sent by Atlassian JIRA
(v6.1#6144)