Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAHdjipJeOhsepR99+hUkG-H4QLaSDm6mhu81S=ghWP99Gk2crA@mail.gmail.com>
References: <529DE44C.4090400@bigbluehat.com>
	<529DFA3E.3010706@gmail.com>
	<CAHdjipJ0J_8zj2z3y1DbfbGHHVhx4LVGGF2AGkQkC+t5NGPQPw@mail.gmail.com>
	<529E20E8.2070900@bigbluehat.com>
	<CAHdjipJeOhsepR99+hUkG-H4QLaSDm6mhu81S=ghWP99Gk2crA@mail.gmail.com>
Date: Tue, 3 Dec 2013 18:40:01 +0000
Message-ID: 
 <CABvT1DHtPHZECbhHsfR9KyYf2g477My0w25q6zV9gAmJ5H7RDw@mail.gmail.com>
Subject: Re: [PROPOSAL] new underscore namespacing
From: Robert Newson <rnewson@apache.org>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

'there could be used optimistic conflict model when couchdb will
disallow atts with names that are already reserved by handlers'

You should flag jokes for the avoidance of doubt.

B.


On 3 December 2013 18:37, Alexander Shorin <kxepal@gmail.com> wrote:
> Instead of /_/ there could be used optimistic conflict model when couchdb
> will disallow atts with names that are already reserved by handlers. IT
> would be like document conflict resolution, but more tricky.
>
> P.S. Sorry fir typos in both mails, wrote them from phone with frozen
> fingers (-10 outside there)
> On Dec 3, 2013 10:20 PM, "Benjamin Young" <byoung@bigbluehat.com> wrote:
>
>>
>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>