You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2020/05/06 11:57:42 UTC
[VOTE]: Deprecate _update Endpoint
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
Re: [VOTE]: Deprecate _update Endpoint
Posted by Robert Samuel Newson <rn...@apache.org>.
+1.
> On 6 May 2020, at 12:57, Jan Lehnardt <ja...@apache.org> 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
>
Re: [VOTE]: Deprecate _update Endpoint
Posted by Jan Lehnardt <ja...@apache.org>.
> On 6. May 2020, at 17:40, Adam Kocoloski <ko...@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 <va...@gmail.com> wrote:
>>
>> +1
>>
>>
>>> On May 6, 2020, at 08:04, Jonathan Hall <fl...@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
>>>>
>
Re: [VOTE]: Deprecate _update Endpoint
Posted by Joan Touzet <wo...@apache.org>.
Hi Adam, dev@,
On 2020-05-06 11:40, Adam Kocoloski 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
Thanks for mentioning these.
For the record, I'm happy to help bring 1554 (and, if Jan wishes, 1559)
through to RFCs if people wish, but I can't commit to implementing
either one at this time.
Without someone clearly assigned to drive this to the finish line, I am
uncomfortable with making deprecation of _update contingent upon
implementation of either of these.
-Joan "too busy to code right now" Touzet
> 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.
>
> +0
>
>> On May 6, 2020, at 10:53 AM, Nick V <va...@gmail.com> wrote:
>>
>> +1
>>
>>
>>> On May 6, 2020, at 08:04, Jonathan Hall <fl...@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
>>>>
>
Re: [VOTE]: Deprecate _update Endpoint
Posted by Adam Kocoloski <ko...@apache.org>.
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.
+0
> On May 6, 2020, at 10:53 AM, Nick V <va...@gmail.com> wrote:
>
> +1
>
>
>> On May 6, 2020, at 08:04, Jonathan Hall <fl...@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
>>>
Re: [VOTE]: Deprecate _update Endpoint
Posted by Nick V <va...@gmail.com>.
+1
> On May 6, 2020, at 08:04, Jonathan Hall <fl...@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
>>
Re: [VOTE]: Deprecate _update Endpoint
Posted by Jonathan Hall <fl...@flimzy.com>.
+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
>