My favorites | Sign in
Project Home
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 188: Cant use _replicator database
2 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  ----
Closed:  Sep 2012


Sign in to add a comment
 
Reported by mart...@gmail.com, Jul 4, 2011
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

Jul 4, 2011
Project Member #1 djc.ochtman
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.
Jan 9, 2012
#2 john.po...@lmco.com
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. 
Jan 9, 2012
#3 matt.goo...@gmail.com
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).
Jan 9, 2012
#4 kxepal
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.
Sep 20, 2012
Project Member #5 djc.ochtman
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).
Sep 20, 2012
#6 matt.goo...@gmail.com
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.
Sep 21, 2012
Project Member #7 djc.ochtman
This issue was closed by revision 00d6a78a44cf.
Status: Fixed
Apr 5, 2013
#8 kxepal
 Issue 220  has been merged into this issue.
Apr 5, 2013
#9 kxepal
 Issue 220  has been merged into this issue.
Sign in to add a comment

Powered by Google Project Hosting