couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Young <byo...@bigbluehat.com>
Subject Re: [PROPOSAL] new underscore namespacing
Date Tue, 03 Dec 2013 18:20:24 GMT

On 12/3/13, 1:11 PM, Alexander Shorin wrote:
> +1 for meta. It's cool idea and every doc has some meta info like type field
>
> -1 on /_/ url thing.  It's ugly and not related to reserved namespace: you
> may define any named handler in config file and having _ prefix saves you
> from collision with atts (but it's still optiona)

So collision with attachments is exactly the situation this was proposed 
out of.

Sphinx (for one...among many...), uses "_*" prefixed folders for it's 
styles, templates, etc. So does Github's ghpages.

As such, you have to change how those things work in order to store 
their files in CouchDB.

What I'm after is the ability to dump "whatever" into CouchDB and have 
it work. :) Without having to care about what the database chose to reserve.

The point with "/_/" was to narrow the surface area of the API.

The proposal's uncovered lots of other issues and ideas. Which is great! ;)

> On Dec 3, 2013 7:37 PM, "Volker Mische" <volker.mische@gmail.com> wrote:
>
>> 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
>>
>>
>>
>>


Mime
View raw message