Hi. > the majority view seems to be that these can all be done better externally
As Johs mentioned, it looks like couchapp community here is a sort of minority. I’m sorry to say, but telling minorities what is, well, the right way to use endpoints, is an attitude widely considered at least outdated. Even if the majority think they know how to do better, even if some of them experienced nausea one or two times long ago. Minorities better be embraced, not repelled or expelled. > there doesn't even need to be a performance impact First, this is not always true, and I even know in which particular cases – because I’ve tested. But did you? Secondly, as I pointed out several times, slight performance differences are not always important, for large meshes deployment is much more vital thing. As from deployment pov there is no reasonably lightweight substitute. Best regards, ermouth вс, 8 сент. 2019 г. в 11:33, Robert Samuel Newson <rnew...@apache.org>: > 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. > >
