couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: [PROPOSAL] new underscore namespacing
Date Tue, 03 Dec 2013 19:20:49 GMT
Sorry, miss the smile, but in every joke there is only a piece of joke (;
Anyway there will be collisions since it's old issue about split
predefined and custom resources in RESTful apps and prefix is quite
common way to solve it with less blood.
--
,,,^..^,,,


On Tue, Dec 3, 2013 at 10:40 PM, Robert Newson <rnewson@apache.org> wrote:
> '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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>

Mime
View raw message