Cant use _replicator database

[GoogleCodeExporter]

CouchDB 1.1 has a new special database with the name _replicator. If you try to 
access this validate_dbnamewill throw an exception because it isn't defined in 
SPECIAL_DB_NAMES

Original issue reported on code.google.com by mart...@gmail.com on 4 Jul 2011 at 3:43

[GoogleCodeExporter]

Right. We should release an update, we've had this fixed for a while now. You 
should probably hack it into SPECIAL_DB_NAMES for now.

Original comment by djc.ochtman on 4 Jul 2011 at 3:46

[GoogleCodeExporter]

The problem is that valid_dbname should not be called when one is trying to 
access a database.  There is really no need for it, so the better solution is 
to remove all call to valid_dbname on database access. 

Original comment by john.po...@lmco.com on 9 Jan 2012 at 6:44

[GoogleCodeExporter]

Yep, I agree. There has been some discussion about this on the mailing list and 
I have something part done but not quite finished.

IIRC, the only real problem is that validate_dbname() raises a specific 
exception (ValueError, from memory) so the exception from the server needs 
mapping to that to avoid breaking the couchdb-python API. So, that means making 
a GET to CouchDB (HEAD is no good because it doesn't include a specific enough 
error), checking for any error, and re-raising as necessary.

The thing is, and I've been meaning to raise this on the mailing list for a 
while, is that validate_dbname() is only used in a couple of places in the API 
right now so the ValueError isn't actually raised very consistently.

I would expect couchdb-python to *always* raise a ValueError or just let the 
HTTP exception fall through and let the application deal with it. Part of me 
doesn't want to break API but the other part wants to let the HTTP'ness shine 
through more (which also results in simple couchdb-python code).

Original comment by matt.goo...@gmail.com on 9 Jan 2012 at 7:28

[GoogleCodeExporter]

Some thoughts to say:
1. You may attach external CouchDB database using couch_httpd_proxy which would 
be hidden from db list, but still available. 
2. There is opened ticked and patch that allows to create custom special 
databases https://issues.apache.org/jira/browse/COUCHDB-1352 so _users and 
_replicator wouldn't be a special case anymore.
3. There could be other special databases for various CouchDB distributions, 
plugins, etc.
Summarizing: with own list of special db names couchdb-python risking to lose 
compatibility sooner or later with some CouchDB distributions / 
configurations(assuming that package is always up-to-dated).

However, current dbname restriction has very simple workaround:
>>> db = couchdb.Database('http://localhost:5984/_replicator')
or
>>> server = couchdb.Server()
>>> url = server.resource('_replicator').url
>>> db = couchdb.Database(url)

So what the real cost of validate_dbname function after that? Its very helpful 
when you makes typo, but it __could be__ harmful if validate_dbname has 
different logic from CouchDB server and useless if you still want to get 
forbidden database.

Also, SPECIAL_DB_NAMES wouldn't safe you from next behavior:
0. Add '_replicator' database to SPECIAL_DB_NAMES
1. Downgrade CouchDB from 1.1.0 to 1.0.3. 
2. Try to access to _replicator database.
You will fail due to HTTP error about invalid database name, because 
_replicator database is not valid for 1.0.3 version, but still is for 1.1.0.

That's my story about this problem(:

Solution? Probably, leave check (regexp) and apply it for database creation, 
but remove it for database requesting(Server.__getitem__) and others. 
Motivation:
1. If I set dbname manually I'm ensure in it. I just should to be(: Typos is my 
own fault.
2. If I get dbname from outside I never should trust it and should check that 
it is correct and result is valid database resource. If I doesn't - this is my 
own fault and only.
3. But I could forget database name restrictions on creation and there 
validate_dbname() helps me to not disturb server one more time.
4. About other usages of validate_dbname():
4.1 Server.__contains__ should return False on invalid dbname because this is 
True(: You'll still get ValueError on attempt of it creation.
4.2 Server.__delitem__ probably could have it removed for consistency.

Original comment by kxepal on 9 Jan 2012 at 9:37

[GoogleCodeExporter]

I've added _replicator to SPECIAL_DB_NAMES for now, let's further discuss the 
other issues here. I tend to agree with Alexander that we should only check 
dbnames for database creation, and leave it to the HTTP layer to error out on 
using databases with invalid names (even though it'll break the API a little 
bit).

Original comment by djc.ochtman on 20 Sep 2012 at 8:05

[GoogleCodeExporter]

Personally, I'm all for letting CouchDB report the error and removing 
validate_dbname() completely. It breaks API a little, but I think it's worth it.

Original comment by matt.goo...@gmail.com on 20 Sep 2012 at 6:46

[GoogleCodeExporter]

This issue was closed by revision 00d6a78a44cf.

Original comment by djc.ochtman on 21 Sep 2012 at 7:54

• Changed state: Fixed

[GoogleCodeExporter]

Issue 220 has been merged into this issue.

Original comment by kxepal on 6 Apr 2013 at 6:09

[GoogleCodeExporter]

Issue 220 has been merged into this issue.

Original comment by kxepal on 6 Apr 2013 at 6:14