On 12/03/2013 03:01 PM, Benjamin Young wrote: > 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 > attachments. > - _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._.id, > 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, > Benjamin > > [1] http://stateless.co/hal_specification.html > [2] https://github.com/blongden/vnd.error
Hi, I personally would prefer to have the meta information completely separate from the document. I know there have been discussion in the past to even have them separate in the backend (but that's not the point of this proposal). So the API for the view function could change to `function(doc, meta)`. This way you could store in your document whatever you like. Cheers, Volker
