> On 6. May 2020, at 17:40, Adam Kocoloski <kocol...@apache.org> wrote:
>
> When we looked at some of our internal usage data we found that _update had
> measurably higher adoption than the rendering functions, so we didn’t push so
> hard on deprecating it yet.
>
> I’d feel better about removing this endpoint if there was a clear plan to
> provide alternative server-side partial update functionality in a future
> release. We had some good discussions in GitHub a while back:
>
> https://github.com/apache/couchdb/issues/1554
> https://github.com/apache/couchdb/issues/1559
>
> It’d be good to review those designs and see if we can advance them to the
> level of an RFC. I suspect we’re close.
I agree it’d be nice to have those to issues closed out and there isn’t a lot
to making that happen conceptually, so I’m reasonable confident we’ll get there
eventually. But I’d rather not make those landing a precondition of the
deprecation.
Best
Jan
—
>
> +0
>
>> On May 6, 2020, at 10:53 AM, Nick V <vatam...@gmail.com> wrote:
>>
>> +1
>>
>>
>>> On May 6, 2020, at 08:04, Jonathan Hall <fli...@flimzy.com> wrote:
>>>
>>> +1
>>>
>>>> On 5/6/20 1:57 PM, Jan Lehnardt wrote:
>>>> Hey all,
>>>>
>>>> it appears we missed an item in our 3.0 deprecations list and we should
>>>> clear this up.
>>>>
>>>> We have as of yet failed to capture consensus here about the
>>>> deprecation of the _update endpoint. I think we *have* consensus here,
>>>> but we didn’t make it stick in writing.
>>>>
>>>> To recap: the _update endpoint was added to allow arbitrary data to be
>>>> POSTed to CouchDB and for developers to take whatever and turn that
>>>> into a JSON document that then gets stored into CouchDB. Initially,
>>>> this was added so we can process HTML Form submits. With the advent of
>>>> XHR/fetch in browsers, this is no longer necessary. Another aim at the
>>>> time was allowing legacy data systems that e.g. send XML via HTTP to
>>>> configurable URLs to directly integrate with CouchDB. This is still a
>>>> valid use-case, but easily enough worked around.
>>>>
>>>> There is also a constant level of confusion with the similarly named
>>>> validate_doc_update feature, which enforces access control and schema
>>>> conformity on all document writes. There is no proposal to deprecate
>>>> this feature at this point and the _update endpoint and functionality
>>>> are fully distinct from validate_doc_update.
>>>>
>>>> _update is the logical reverse of a _show and we already have
>>>> deprecated that. It follows that we also deprecate _update for the same
>>>> reasons (which I’m not going to rehash here for the 400th time).
>>>>
>>>> Since this is an API deprecation as per our bylaws[1], please cast your
>>>> votes (or abstain to agree, as per lazy-consensus).
>>>>
>>>> Best
>>>> Jan “XML, in this economy?” Lehnardt
>>>> —
>>>> [1]: https://couchdb.apache.org/bylaws.html#api
>>>>
>
