couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Young <>
Subject [PROPOSAL] new underscore namespacing
Date Tue, 03 Dec 2013 14:01:48 GMT
Hi all,

Recently the "doc._*" reservation has been causing me trouble when 
pulling in "arbitrary" JSON from various sources that also use the 
underscore prefixed names for things (HAL [1], vnd.error [2], other 
APIs). I've also hit the wall several times when trying to import 
filesystem contents (Sphinx, ghpages, and the like) that use _* 
prefixing for their "special folders."

As such, I'd like to propose the following:
1. Begin storing new reserved terms in doc._.* (rather than doc._*).
  - this gives developers one object to look into for the meta-data 
about a doc
  - you can see the scope creep of our current doc._* best in the 
replicator status messages.
     - doc._ replication_* would become doc._.replication.*
2. Move "magic" API endpoints under "/_/" term as well (for the sake of 
  - _design/doc would stay the same
  - but the child endpoints would live under "_design/doc/_/*"
     - _design/doc/_/view/by_date
     - _design/doc/_/list/by_date/ul
     - _design/doc/_/rewrite

I realize these are extreme API shifts, and would need to wait for 
CouchDB 2.0.

The first steps this direction would be to put new reserved word keys 
into a "doc._.*" namespace going forward. Closer to the "cut over" for 
2.0 duplicates of the existing keys (doc._id, doc._rev, especially) 
could also live at their new underscore prefixed names (, 
doc._.rev) which would give devs a chance to migrate code and content.

Doing this would:
1. Give us "limitless" space to add content.
2. Encourage a namespacing pattern for things like doc._.replication.* 
or other logically grouped content.
3. Free up CouchDB to accept a far broader range of content and remove 
the "hey, you can't put that there! I was here first!" errors. :)

Thanks for considering this,


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message