Hi, My rule of thumb here is whether any particular 'data processing endpoint' can be done better (or at all) within the database server than otherwise, as opposed to the original CouchDB position of adding such things to the database to enable application hosting (of a limited form, as we've all noted ad nauseam). For _show, _list, _rewrite and _update, the majority view seems to be that these can all be done better externally. With Joan's note on co-locating couchdb, node.js and a proxy like nginx or haproxy, there doesn't even need to be a performance impact.
I think Joan might have been referring to "validate_doc_update" not "_update" with the "going nowhere" comment, as I think we all agree that validate_doc_update is an important part of the core database (though it might be enhanced to not require a javascript evaluation in most circumstances) or at least something like it that allows users to enforce arbitrary constraints on the form of any given update. In summary, I still think we're deprecating several of the 'data processing endpoints' in 3.0 and removing them (or not re-implementing them as the case may be) in 4.0. CouchDB 3.0 will be around for some time to come. B. > On 7 Sep 2019, at 04:13, Johs Ensby <j...@b2w.com> wrote: > > Hi Joan, > >> On 7 Sep 2019, at 00:59, Joan Touzet <woh...@apache.org> wrote: >> 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. > > About the discussions on dropping the functions that make design documents so > useful to many of us: > Thanks again for clarifying. > > This provides predictability for a group of users that might otherwise feel > like a week minory. > Together with Jan's LTS commitment in the August report below, this > predictability is highly appreciated. > >> On 19 Aug 2019, at 11:51, Jan Lehnardt <j...@apache.org> wrote: >> >> 3.0 >> will include the best version of the current, mostly Erlang-based project, >> with many new features contributed by various project partners (but notably >> IBM). This will be the LTS version for people who won’t be able to migrate to >> the newer technology foundation. There are a number of technical limitations >> that we are happy to adopt as a project going forward, but that might be >> deal- >> breakers for some users. As such, we’ll serve those users best with an >> excellent >> edition of the original technology stack. LTS-timelines are TBD. >> > > > Johs > > PS >> On 7 Sep 2019, at 00:59, Joan Touzet <woh...@apache.org> wrote: >> 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: > As for the discussion about CouchDB as a catch-all platform (node.js, > haproxy, and nginx etc) – it is lost and buried. > Thanks to @ermouth for narrowing down this to "prossesing endpoints" and > "data pre/post prossessing", useful terms in redirecting the discussion > towards the usefulness of design documents that sync can with the data.
