Hi Robert,
As long as design documents have meaningful processing endpoints, they will
remain the extremely useful babel fish of CouchDB.
Does your "for some time to come” mean that you support a LTS for 3.0?
(ref Jan 19 Aug 2019)
Johs
> On 8 Sep 2019, at 16:24, ermouth wrote:
>
> Hi.
>
>>
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 outdat
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 a
Hi Joan,
> On 7 Sep 2019, at 00:59, Joan Touzet 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
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 _
I’d like to raise QS functions deprecation question again, in a somehow
different aspect.
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 deriva
