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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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" <[email protected]> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>
