On 2019-09-06 6:25 p.m., ermouth wrote:
I’d like to raise QS functions deprecation question again, in a somehow
different aspect.
What is "QS functions"? Which specific deprecations in 3.0 are you
asking about? Is it just _list, _update and _rewrites? Of these, _update
is going nowhere, and _list and _rewrites don't go away until 4.0.
More accurately, the current plan is they won't be re-implemented for
4.0, since the existing implementations won't work in 4.0 against
FoundationDB.
Statistically, ‘couchapp’ term has unfortunate history: many tried what
they thought were couchapps, most expected too much – and were bitterly
disappointed. I have better experience with couchapps and derivatives, but
technologies and tooling used are very far from mainstream concepts.
Anyway, we played a lot with QS, and discovered that _list, _update and,
later, js _rewrite have another point of application, much more significant
than rendering HTML in a cumbersome manner.
QS functions, being distributed with main data flow, allow comprehensive
in-place data pre- and post-processing, very unique feature across DB
landscape.
We've had this discussion before. I don't see you saying anything new,
and I'm not going to repeat myself, ether.
So, probably it would be better not to deprecate/remove those endpoints in
Couch 3, but just ditch the ‘couchapp’ term in favor of something like
‘data processing extensions’.
We've already dropped the 'couchapp' term in the documentation, over a
year ago. There is a single reference to them in the docs that states
these functions should not be used for new designs:
http://docs.couchdb.org/en/stable/ddocs/index.html?highlight=couchapp
The deprecation table of the 4 endpoints proposed for deprecation in 4.0
includes the suggested replacements for these functions in 4.0. Yes,
this isn't all done 100% in CouchDB, but even a RaspberryPi can run an
haproxy, an nginx or a small Node.JS server alongside CouchDB with
almost no CPU impact - in fact, less CPU and RAM impact than using
_list, _show or _rewrite in CouchDB today.
That's not to say that this stuff - server-side mass updates of
documents, to take one often requested example - might not end up being
implemented *better* than these functions, with a brand new API, thanks
to what FoundationDB provides. (But that functionality may not land in
time for 4.0, either.)
Seems, QS functions in current state require very minor maintenance and
have nearly zero bugs. So why spend time amputating working parts,
shouldn’t it be better to transform them into clearly presented advantage?
See above - the current implementations won't work in 4.0 and would need
a complete rewrite. This isn't a "keep the code around" situation, it's
a full re-engineering effort. Our individual experiences have lead us to
different places on this functionality, we've heard from everyone active
in this community at least *twice* about their viewpoints.
Speaking as fairly as possible, I don't practically see this
disagreement being resolved in an easy fashion at this point.
-Joan
I mean changes in docs, removing ‘couchapps’ in favor of ‘processing
extensions’, maybe introducing less expensive requestObj, etc. Clarifying
language:"erlang" usage might also be valuable. Anyway, creative work, not
destructive.
ermouth
