Re: Proposed deprecations / removals (was: Re: Getting started on CouchDB 3.0, and an introduction)

2019-10-02 Thread Joan Touzet 



On 2019-10-02 15:10, Denitsa Burroughs wrote:
> Hi Joan, Adam, et al,
> 
> Ilya and I got together to review the deprecations list to a) determine if
> there were any additional breaking changes required for 3.0 and b) ensure
> we had a comprehensive list for documentation and release notes purposes.
> We used this email thread and the tickets Adam created as a starting point.
> Ilya identified a few other items that were missing from the lists. We've
> summarized the changes in https://github.com/apache/couchdb/issues/2218

Added to 3.0 in the project.

> This ticket is specific to 3.0. Hopefully it would simplify the release
> notes process. Please take a look - we are missing some of the
> reference/decision links and some of the deprecations are not complete or
> documented yet. (I will work with Ilya to update the table as we go since I
> don't have edit permissions yet).
> 
> Proposed 1.x deprecations 
> was also mentioned  and is currently in the 3.0 tasks column. Should we
> close this ticket? It appears quite old. Is there any information that
> needs to be extracted and is required for 3.0?

Closed out. This mailing list discussion is definitive; that ticket
lived long past its useful lifetime.

> Thanks,
> 
> Deni
> 
> 
> 
> On Mon, Sep 16, 2019 at 4:19 PM Adam Kocoloski  wrote:
> 
>> I added https://github.com/apache/couchdb/issues/2191 to the 3.0 release
>> tasks but I don’t know exactly what the desired end state looks like there.
>>
>> Adam
>>
>>> On Sep 14, 2019, at 3:11 PM, Joan Touzet  wrote:
>>>
>>> Hi Deni, I think you mean Joan, not Jan. :D
>>>
>>> As I mentioned there isn't an issue yet, so we need to create one. I'm
>> away from my credentials until Tuesday and can address this then, if no one
>> gets to it first.
>>>
>>> -Joan
>>>
>>> On 2019-09-11 2:43 p.m., Denitsa Burroughs wrote:
 Hi Jan -
 Do you happen to have the ticket/link for this?
> I remembered one last deprecation we wanted in 3.0: security
>> tightening,
> which included the deprecation of admin party.
>
 Thanks!
 Deni
 On Mon, Sep 9, 2019 at 2:14 PM Joan Touzet  wrote:
> I remembered one last deprecation we wanted in 3.0: security
>> tightening,
> which included the deprecation of admin party.
>
> Jan can you find the ticket on this? I don't think it's the full #1504.
> Just new defaults, and we'll need to think thru what happens when
> starting up a node that has no [admins]. Do we create one and log its
> password to the logfile? What if logging is disabled / goes nowhere? Or
> do we simply refuse to start until an admin is created? What about
> crypting and salting the password ahead of time - do we introduce a
> small cli tool to generate passwords like apache/httpd does? Many
> questions.
>
> -Joan
>
>
> On 2019-09-04 5:37 p.m., Joan Touzet wrote:
>> Hey Adam,
>>
>>> When it comes to deprecating and/or removing functionality, I feel
>> like
> I don’t know exactly where we stand today. We have occasionally
>> described
> some of the CouchApp functionality as already being deprecated, but I’m
> having trouble finding any official record of that in our
>> documentation.
>> Thanks for re-opening the deprecation discussion. I've reviewed [1]
>> and
>> provide the following summary tables (Markdown format).
>>
>> **NOTE**: This is /not/ the vote for deprecation, nor a formal
>> announcement of such. This is a starting point for discussion. A vote
>> still needs to happen for this to move forward. Anything already
>> deprecated in 2.0 can be removed in 3.0 without a formal vote, but
>> it'd
>> be nice if it got mentioned on the dev@ list before the PR lands on
>> master, please.
>>
>> As I'm going to be travelling for most of the rest of September, I'd
>> prefer if someone else (like Adam or Deni) can help drive this
> discussion.
>>
>> Once there is consensus from the community on these lists, we should
>> close #1534 and split it into 3 new tickets based on the tables below
>> (excepting the features already removed in 2.x).
>>
>>> I guess let’s start with: does anyone believe we are in a position to
> be eliminating previously-deprecated functionality in 3.0?
>>
>> Yes, for the items in the 2nd table below, absolutely.
>>
>> -Joan "turning the tables" Touzet
>>
>>
>> 
>>
>>
>> # Recently removed features in 2.x
>>
>> **Feature/Endpoint**| **Links**
>> |
>> update_notifications| [10]
>> ini-file based query servers| [11]
>> ini-file based HTTP global handlers | [11]
>> OS daemons  | [11],[12]
>> vhost redirects/global handlers | [11],[12]
>> couch_httpd_proxy

Re: Proposed deprecations / removals (was: Re: Getting started on CouchDB 3.0, and an introduction)

2019-10-02 Thread Denitsa Burroughs 
Hi Joan, Adam, et al,

Ilya and I got together to review the deprecations list to a) determine if
there were any additional breaking changes required for 3.0 and b) ensure
we had a comprehensive list for documentation and release notes purposes.
We used this email thread and the tickets Adam created as a starting point.
Ilya identified a few other items that were missing from the lists. We've
summarized the changes in https://github.com/apache/couchdb/issues/2218
This ticket is specific to 3.0. Hopefully it would simplify the release
notes process. Please take a look - we are missing some of the
reference/decision links and some of the deprecations are not complete or
documented yet. (I will work with Ilya to update the table as we go since I
don't have edit permissions yet).

Proposed 1.x deprecations 
was also mentioned  and is currently in the 3.0 tasks column. Should we
close this ticket? It appears quite old. Is there any information that
needs to be extracted and is required for 3.0?

Thanks,

Deni



On Mon, Sep 16, 2019 at 4:19 PM Adam Kocoloski  wrote:

> I added https://github.com/apache/couchdb/issues/2191 to the 3.0 release
> tasks but I don’t know exactly what the desired end state looks like there.
>
> Adam
>
> > On Sep 14, 2019, at 3:11 PM, Joan Touzet  wrote:
> >
> > Hi Deni, I think you mean Joan, not Jan. :D
> >
> > As I mentioned there isn't an issue yet, so we need to create one. I'm
> away from my credentials until Tuesday and can address this then, if no one
> gets to it first.
> >
> > -Joan
> >
> > On 2019-09-11 2:43 p.m., Denitsa Burroughs wrote:
> >> Hi Jan -
> >> Do you happen to have the ticket/link for this?
> >>> I remembered one last deprecation we wanted in 3.0: security
> tightening,
> >>> which included the deprecation of admin party.
> >>>
> >> Thanks!
> >> Deni
> >> On Mon, Sep 9, 2019 at 2:14 PM Joan Touzet  wrote:
> >>> I remembered one last deprecation we wanted in 3.0: security
> tightening,
> >>> which included the deprecation of admin party.
> >>>
> >>> Jan can you find the ticket on this? I don't think it's the full #1504.
> >>> Just new defaults, and we'll need to think thru what happens when
> >>> starting up a node that has no [admins]. Do we create one and log its
> >>> password to the logfile? What if logging is disabled / goes nowhere? Or
> >>> do we simply refuse to start until an admin is created? What about
> >>> crypting and salting the password ahead of time - do we introduce a
> >>> small cli tool to generate passwords like apache/httpd does? Many
> >>> questions.
> >>>
> >>> -Joan
> >>>
> >>>
> >>> On 2019-09-04 5:37 p.m., Joan Touzet wrote:
>  Hey Adam,
> 
> > When it comes to deprecating and/or removing functionality, I feel
> like
> >>> I don’t know exactly where we stand today. We have occasionally
> described
> >>> some of the CouchApp functionality as already being deprecated, but I’m
> >>> having trouble finding any official record of that in our
> documentation.
>  Thanks for re-opening the deprecation discussion. I've reviewed [1]
> and
>  provide the following summary tables (Markdown format).
> 
>  **NOTE**: This is /not/ the vote for deprecation, nor a formal
>  announcement of such. This is a starting point for discussion. A vote
>  still needs to happen for this to move forward. Anything already
>  deprecated in 2.0 can be removed in 3.0 without a formal vote, but
> it'd
>  be nice if it got mentioned on the dev@ list before the PR lands on
>  master, please.
> 
>  As I'm going to be travelling for most of the rest of September, I'd
>  prefer if someone else (like Adam or Deni) can help drive this
> >>> discussion.
> 
>  Once there is consensus from the community on these lists, we should
>  close #1534 and split it into 3 new tickets based on the tables below
>  (excepting the features already removed in 2.x).
> 
> > I guess let’s start with: does anyone believe we are in a position to
> >>> be eliminating previously-deprecated functionality in 3.0?
> 
>  Yes, for the items in the 2nd table below, absolutely.
> 
>  -Joan "turning the tables" Touzet
> 
> 
>  
> 
> 
>  # Recently removed features in 2.x
> 
>  **Feature/Endpoint**| **Links**
>  |
>  update_notifications| [10]
>  ini-file based query servers| [11]
>  ini-file based HTTP global handlers | [11]
>  OS daemons  | [11],[12]
>  vhost redirects/global handlers | [11],[12]
>  couch_httpd_proxy   | [11],[12]
> 
>  *NOTE*: Some of these still have lingering bits in the documentation
>   that need a final cleanup pass before 3.0 should be released.
> 
>  
> 
>  # Already deprecated items, to be

Re: Proposed deprecations / removals (was: Re: Getting started on CouchDB 3.0, and an introduction)

2019-09-16 Thread Adam Kocoloski 
I added https://github.com/apache/couchdb/issues/2191 to the 3.0 release tasks 
but I don’t know exactly what the desired end state looks like there.

Adam

> On Sep 14, 2019, at 3:11 PM, Joan Touzet  wrote:
> 
> Hi Deni, I think you mean Joan, not Jan. :D
> 
> As I mentioned there isn't an issue yet, so we need to create one. I'm away 
> from my credentials until Tuesday and can address this then, if no one gets 
> to it first.
> 
> -Joan
> 
> On 2019-09-11 2:43 p.m., Denitsa Burroughs wrote:
>> Hi Jan -
>> Do you happen to have the ticket/link for this?
>>> I remembered one last deprecation we wanted in 3.0: security tightening,
>>> which included the deprecation of admin party.
>>> 
>> Thanks!
>> Deni
>> On Mon, Sep 9, 2019 at 2:14 PM Joan Touzet  wrote:
>>> I remembered one last deprecation we wanted in 3.0: security tightening,
>>> which included the deprecation of admin party.
>>> 
>>> Jan can you find the ticket on this? I don't think it's the full #1504.
>>> Just new defaults, and we'll need to think thru what happens when
>>> starting up a node that has no [admins]. Do we create one and log its
>>> password to the logfile? What if logging is disabled / goes nowhere? Or
>>> do we simply refuse to start until an admin is created? What about
>>> crypting and salting the password ahead of time - do we introduce a
>>> small cli tool to generate passwords like apache/httpd does? Many
>>> questions.
>>> 
>>> -Joan
>>> 
>>> 
>>> On 2019-09-04 5:37 p.m., Joan Touzet wrote:
 Hey Adam,
 
> When it comes to deprecating and/or removing functionality, I feel like
>>> I don’t know exactly where we stand today. We have occasionally described
>>> some of the CouchApp functionality as already being deprecated, but I’m
>>> having trouble finding any official record of that in our documentation.
 Thanks for re-opening the deprecation discussion. I've reviewed [1] and
 provide the following summary tables (Markdown format).
 
 **NOTE**: This is /not/ the vote for deprecation, nor a formal
 announcement of such. This is a starting point for discussion. A vote
 still needs to happen for this to move forward. Anything already
 deprecated in 2.0 can be removed in 3.0 without a formal vote, but it'd
 be nice if it got mentioned on the dev@ list before the PR lands on
 master, please.
 
 As I'm going to be travelling for most of the rest of September, I'd
 prefer if someone else (like Adam or Deni) can help drive this
>>> discussion.
 
 Once there is consensus from the community on these lists, we should
 close #1534 and split it into 3 new tickets based on the tables below
 (excepting the features already removed in 2.x).
 
> I guess let’s start with: does anyone believe we are in a position to
>>> be eliminating previously-deprecated functionality in 3.0?
 
 Yes, for the items in the 2nd table below, absolutely.
 
 -Joan "turning the tables" Touzet
 
 
 
 
 
 # Recently removed features in 2.x
 
 **Feature/Endpoint**| **Links**
 |
 update_notifications| [10]
 ini-file based query servers| [11]
 ini-file based HTTP global handlers | [11]
 OS daemons  | [11],[12]
 vhost redirects/global handlers | [11],[12]
 couch_httpd_proxy   | [11],[12]
 
 *NOTE*: Some of these still have lingering bits in the documentation
  that need a final cleanup pass before 3.0 should be released.
 
 
 
 # Already deprecated items, to be removed in 3.0
 
 **Feature/Endpoint**| **Links**
 |
 some duplicate dbinfo size fields   | [2],[3]
 delayed_commits | [4]
 port 5986   | [5],[6]
 `/{db}/_external/*` | [7],[8]
 view-based changes (code remnants)  | [17],[18],[19],[20]
 
 
 
 # Proposed deprecations for 3.0, not rebuilt/removed in 4.0
 
 **Feature/Endpoint**   |**Replaced by**   | **Links**
 --|--|---
 `/{db}/{ddoc}/_show/*`| App server/rev proxy | †
 `/{db}/{ddoc}/_list/*`| App server/rev proxy | †
 virtual hosts [24]| haproxy, multitenant | [25]
 `/{db}/{ddoc}/_rewrite/*` | App server/rev proxy | [26]
 
 †: getRow() makes embedding a new, efficient JS engine impossible since
 getRow() does not give up thread execution control; an entirely new
 approach would need to be constructed, breaking backward compatibility
 at the very least. (There are additional challenges.)
 
 
 
 # Likely will remain unchanged through 4.0
 
 **Feature/Endpoint**  |**Improved by**

Re: Proposed deprecations / removals (was: Re: Getting started on CouchDB 3.0, and an introduction)

2019-09-14 Thread Joan Touzet 

Hi Deni, I think you mean Joan, not Jan. :D

As I mentioned there isn't an issue yet, so we need to create one. I'm 
away from my credentials until Tuesday and can address this then, if no 
one gets to it first.


-Joan

On 2019-09-11 2:43 p.m., Denitsa Burroughs wrote:

Hi Jan -
Do you happen to have the ticket/link for this?


I remembered one last deprecation we wanted in 3.0: security tightening,
which included the deprecation of admin party.



Thanks!

Deni

On Mon, Sep 9, 2019 at 2:14 PM Joan Touzet  wrote:


I remembered one last deprecation we wanted in 3.0: security tightening,
which included the deprecation of admin party.

Jan can you find the ticket on this? I don't think it's the full #1504.
Just new defaults, and we'll need to think thru what happens when
starting up a node that has no [admins]. Do we create one and log its
password to the logfile? What if logging is disabled / goes nowhere? Or
do we simply refuse to start until an admin is created? What about
crypting and salting the password ahead of time - do we introduce a
small cli tool to generate passwords like apache/httpd does? Many
questions.

-Joan


On 2019-09-04 5:37 p.m., Joan Touzet wrote:

Hey Adam,


When it comes to deprecating and/or removing functionality, I feel like

I don’t know exactly where we stand today. We have occasionally described
some of the CouchApp functionality as already being deprecated, but I’m
having trouble finding any official record of that in our documentation.

Thanks for re-opening the deprecation discussion. I've reviewed [1] and
provide the following summary tables (Markdown format).

**NOTE**: This is /not/ the vote for deprecation, nor a formal
announcement of such. This is a starting point for discussion. A vote
still needs to happen for this to move forward. Anything already
deprecated in 2.0 can be removed in 3.0 without a formal vote, but it'd
be nice if it got mentioned on the dev@ list before the PR lands on
master, please.

As I'm going to be travelling for most of the rest of September, I'd
prefer if someone else (like Adam or Deni) can help drive this

discussion.


Once there is consensus from the community on these lists, we should
close #1534 and split it into 3 new tickets based on the tables below
(excepting the features already removed in 2.x).


I guess let’s start with: does anyone believe we are in a position to

be eliminating previously-deprecated functionality in 3.0?


Yes, for the items in the 2nd table below, absolutely.

-Joan "turning the tables" Touzet





# Recently removed features in 2.x

**Feature/Endpoint**| **Links**
|
update_notifications| [10]
ini-file based query servers| [11]
ini-file based HTTP global handlers | [11]
OS daemons  | [11],[12]
vhost redirects/global handlers | [11],[12]
couch_httpd_proxy   | [11],[12]

*NOTE*: Some of these still have lingering bits in the documentation
  that need a final cleanup pass before 3.0 should be released.



# Already deprecated items, to be removed in 3.0

**Feature/Endpoint**| **Links**
|
some duplicate dbinfo size fields   | [2],[3]
delayed_commits | [4]
port 5986   | [5],[6]
`/{db}/_external/*` | [7],[8]
view-based changes (code remnants)  | [17],[18],[19],[20]



# Proposed deprecations for 3.0, not rebuilt/removed in 4.0

 **Feature/Endpoint**   |**Replaced by**   | **Links**
--|--|---
`/{db}/{ddoc}/_show/*`| App server/rev proxy | †
`/{db}/{ddoc}/_list/*`| App server/rev proxy | †
virtual hosts [24]| haproxy, multitenant | [25]
`/{db}/{ddoc}/_rewrite/*` | App server/rev proxy | [26]

†: getRow() makes embedding a new, efficient JS engine impossible since
getRow() does not give up thread execution control; an entirely new
approach would need to be constructed, breaking backward compatibility
at the very least. (There are additional challenges.)



# Likely will remain unchanged through 4.0

 **Feature/Endpoint**  |**Improved by**
-|--
VDU (validatefun()) [13] | [14],[15]
update handlers (updatefun) [16] | [14],[15]
JS engine [21]   | [22],[23]
system DB special handling   | [27]

*NOTE*: The last table may grow as limitations imposed by FDB are better
  understood.



# References

[1]: https://github.com/apache/couchdb/issues/1534
[2]:


https://docs.couchdb.org/en/stable/api/database/common.html?highlight=disk-size#get--db

[3]: https://github.com/apache/couchdb/pull/2163
[4]:


https://github.com/apache/couchdb/blob/103a0624f309ea0d796176a55eb5faea68f26047/test/javascript/tests/delayed_commits.js#L16

[5]:

Re: Proposed deprecations / removals (was: Re: Getting started on CouchDB 3.0, and an introduction)

2019-09-11 Thread Denitsa Burroughs 
Hi Jan -
Do you happen to have the ticket/link for this?

> I remembered one last deprecation we wanted in 3.0: security tightening,
> which included the deprecation of admin party.
>

Thanks!

Deni

On Mon, Sep 9, 2019 at 2:14 PM Joan Touzet  wrote:

> I remembered one last deprecation we wanted in 3.0: security tightening,
> which included the deprecation of admin party.
>
> Jan can you find the ticket on this? I don't think it's the full #1504.
> Just new defaults, and we'll need to think thru what happens when
> starting up a node that has no [admins]. Do we create one and log its
> password to the logfile? What if logging is disabled / goes nowhere? Or
> do we simply refuse to start until an admin is created? What about
> crypting and salting the password ahead of time - do we introduce a
> small cli tool to generate passwords like apache/httpd does? Many
> questions.
>
> -Joan
>
>
> On 2019-09-04 5:37 p.m., Joan Touzet wrote:
> > Hey Adam,
> >
> >> When it comes to deprecating and/or removing functionality, I feel like
> I don’t know exactly where we stand today. We have occasionally described
> some of the CouchApp functionality as already being deprecated, but I’m
> having trouble finding any official record of that in our documentation.
> > Thanks for re-opening the deprecation discussion. I've reviewed [1] and
> > provide the following summary tables (Markdown format).
> >
> > **NOTE**: This is /not/ the vote for deprecation, nor a formal
> > announcement of such. This is a starting point for discussion. A vote
> > still needs to happen for this to move forward. Anything already
> > deprecated in 2.0 can be removed in 3.0 without a formal vote, but it'd
> > be nice if it got mentioned on the dev@ list before the PR lands on
> > master, please.
> >
> > As I'm going to be travelling for most of the rest of September, I'd
> > prefer if someone else (like Adam or Deni) can help drive this
> discussion.
> >
> > Once there is consensus from the community on these lists, we should
> > close #1534 and split it into 3 new tickets based on the tables below
> > (excepting the features already removed in 2.x).
> >
> >> I guess let’s start with: does anyone believe we are in a position to
> be eliminating previously-deprecated functionality in 3.0?
> >
> > Yes, for the items in the 2nd table below, absolutely.
> >
> > -Joan "turning the tables" Touzet
> >
> >
> > 
> >
> >
> > # Recently removed features in 2.x
> >
> > **Feature/Endpoint**| **Links**
> > |
> > update_notifications| [10]
> > ini-file based query servers| [11]
> > ini-file based HTTP global handlers | [11]
> > OS daemons  | [11],[12]
> > vhost redirects/global handlers | [11],[12]
> > couch_httpd_proxy   | [11],[12]
> >
> > *NOTE*: Some of these still have lingering bits in the documentation
> >  that need a final cleanup pass before 3.0 should be released.
> >
> > 
> >
> > # Already deprecated items, to be removed in 3.0
> >
> > **Feature/Endpoint**| **Links**
> > |
> > some duplicate dbinfo size fields   | [2],[3]
> > delayed_commits | [4]
> > port 5986   | [5],[6]
> > `/{db}/_external/*` | [7],[8]
> > view-based changes (code remnants)  | [17],[18],[19],[20]
> >
> > 
> >
> > # Proposed deprecations for 3.0, not rebuilt/removed in 4.0
> >
> > **Feature/Endpoint**   |**Replaced by**   | **Links**
> > --|--|---
> > `/{db}/{ddoc}/_show/*`| App server/rev proxy | †
> > `/{db}/{ddoc}/_list/*`| App server/rev proxy | †
> > virtual hosts [24]| haproxy, multitenant | [25]
> > `/{db}/{ddoc}/_rewrite/*` | App server/rev proxy | [26]
> >
> > †: getRow() makes embedding a new, efficient JS engine impossible since
> > getRow() does not give up thread execution control; an entirely new
> > approach would need to be constructed, breaking backward compatibility
> > at the very least. (There are additional challenges.)
> >
> > 
> >
> > # Likely will remain unchanged through 4.0
> >
> > **Feature/Endpoint**  |**Improved by**
> > -|--
> > VDU (validatefun()) [13] | [14],[15]
> > update handlers (updatefun) [16] | [14],[15]
> > JS engine [21]   | [22],[23]
> > system DB special handling   | [27]
> >
> > *NOTE*: The last table may grow as limitations imposed by FDB are better
> >  understood.
> >
> > 
> >
> > # References
> >
> > [1]: https://github.com/apache/couchdb/issues/1534
> > [2]:
> >
> https://docs.couchdb.org/en/stable/api/database/common.html?highlight=disk-size#get--db
> > [3]: https://github.com/apache/couchdb/pull/2163
> > [4]:
> >
>

Re: Proposed deprecations / removals (was: Re: Getting started on CouchDB 3.0, and an introduction)

2019-09-05 Thread Adam Kocoloski 
Tsk, we contributed all of that code without any corresponding documentation? 
Thanks for pointing that out Will, I’ve added it to the list.

Adam

> On Sep 5, 2019, at 5:10 AM, Will Holley  wrote:
> 
> From an operational pov, the compaction daemon was removed in favour of
> smoosh [1]. We owe some documentation around these new subsystems (smoosh,
> ioq, ken) and some guides covering common cases (only compact during quiet
> periods, disable compaction, etc) to aid migration.
> 
> [1] https://github.com/apache/couchdb/pull/1904
> 
> On Thu, 5 Sep 2019 at 03:17, Adam Kocoloski  wrote:
> 
>> I found a couple of other bits while grep’ing through the documentation
>> for “deprecated”:
>> 
>>> * The ``stale`` parameter for views and ``_find`` has been deprecated in
>> favour
>>>  of two new parameters: ``stable`` and ``update``. The old ``stale=ok``
>>>  behaviour is equivalent to ``stable=true=false``, and the old
>>>  ``stale=update_after`` behaviour is equivalent to
>> ``stable=true=lazy``.
>>>  The deprecated ``stale`` parameter will be removed in CouchDB 3.0.
>> 
>> and
>> 
>>> * :ghissue:`820`, :ghissue:`1032`: Multiple queries can now be made at
>> the
>>>  ``POST /{db}/_all_docs/queries``, ``POST /{db}/_design_docs/queries``
>> and
>>>  ``POST /{db}/_local_docs/queries`` endpoints. Also, a new endpoint
>>>  ``POST /{db}/_design/{ddoc}/_view/{view}/queries`` has been introduced
>> to replace
>>>  the ``?queries`` parameter formerly provided for making multiple
>> queries to a view.
>>>  The old ``?queries`` parameter *is now deprecated and will be removed
>> in a future
>>>  release of CouchDB.*
>> 
>> I’m not super-excited about following through on either of those
>> deprecations :) I feel like the `stale` one in particular is still in heavy
>> use. The queries one is probably OK.
>> 
>> On the FDB topic, I believe the transaction logs are configured with the
>> equivalent of delayed_commits=false (thus ensuring the durability of a
>> transaction), while the storage servers only periodically fsync data that
>> they pull off the transaction logs. I don’t think the fsync behavior can be
>> configured using the normal configuration file, but if you go digging into
>> the codebase there’s a Knobs file that has all kinds of settings that
>> shouldn’t be messed with by mere mortals :) I wouldn’t be surprised if some
>> of the durability settings can be tweaked there.
>> 
>> Adam
>> 
>>> On Sep 4, 2019, at 9:13 PM, Joan Touzet  wrote:
>>> 
>>> 
>>> 
>>> On 2019-09-04 20:53, Adam Kocoloski wrote:
 Great list, Joan, thanks. I created a handful of GitHub issues for the
>> first two sections and tossed them in the “Proposed for 3.x” column. I also
>> submitted a PR to address one of them :)
>>> 
>>> Cheers! I've also retitled that column "3.0 Release Tasks" since I think
>>> that's how we're treating it. If it turns out anything needs to be
>>> bumped to 3.x, we can create a new column for that.
>>> 
 Out of that list of already-deprecated functionality the only one that
>> gives me pause is the delayed_commits one. We haven’t talked about it in
>> years, and we ship a safe default. I’d be a little concerned about breaking
>> folks who intentionally switched it on with full knowledge of the tradeoffs.
>>> 
>>> Another option would be to just remove the setting from default.ini and
>>> the documentation.
>>> 
>>> Does FDB have anything similar?
>>> 
>>> -Joan
>>> 
 Adam
 
> On Sep 4, 2019, at 5:44 PM, Johs Ensby  wrote:
> 
> Much appreciated, Joan
> You're a hero
> Johs
> 
>> On 4 Sep 2019, at 23:37, Joan Touzet  wrote:
>> 
>> Hey Adam,
>> 
>>> When it comes to deprecating and/or removing functionality, I feel
>> like I don’t know exactly where we stand today. We have occasionally
>> described some of the CouchApp functionality as already being deprecated,
>> but I’m having trouble finding any official record of that in our
>> documentation.
>> Thanks for re-opening the deprecation discussion. I've reviewed [1]
>> and
>> provide the following summary tables (Markdown format).
>> 
>> **NOTE**: This is /not/ the vote for deprecation, nor a formal
>> announcement of such. This is a starting point for discussion. A vote
>> still needs to happen for this to move forward. Anything already
>> deprecated in 2.0 can be removed in 3.0 without a formal vote, but
>> it'd
>> be nice if it got mentioned on the dev@ list before the PR lands on
>> master, please.
>> 
>> As I'm going to be travelling for most of the rest of September, I'd
>> prefer if someone else (like Adam or Deni) can help drive this
>> discussion.
>> 
>> Once there is consensus from the community on these lists, we should
>> close #1534 and split it into 3 new tickets based on the tables below
>> (excepting the features already removed in 2.x).
>> 
>>> I guess let’s start with: does anyone believe we are in a position
>> to be

Re: Proposed deprecations / removals (was: Re: Getting started on CouchDB 3.0, and an introduction)

2019-09-05 Thread Will Holley 
>From an operational pov, the compaction daemon was removed in favour of
smoosh [1]. We owe some documentation around these new subsystems (smoosh,
ioq, ken) and some guides covering common cases (only compact during quiet
periods, disable compaction, etc) to aid migration.

[1] https://github.com/apache/couchdb/pull/1904

On Thu, 5 Sep 2019 at 03:17, Adam Kocoloski  wrote:

> I found a couple of other bits while grep’ing through the documentation
> for “deprecated”:
>
> > * The ``stale`` parameter for views and ``_find`` has been deprecated in
> favour
> >   of two new parameters: ``stable`` and ``update``. The old ``stale=ok``
> >   behaviour is equivalent to ``stable=true=false``, and the old
> >   ``stale=update_after`` behaviour is equivalent to
> ``stable=true=lazy``.
> >   The deprecated ``stale`` parameter will be removed in CouchDB 3.0.
>
> and
>
> > * :ghissue:`820`, :ghissue:`1032`: Multiple queries can now be made at
> the
> >   ``POST /{db}/_all_docs/queries``, ``POST /{db}/_design_docs/queries``
> and
> >   ``POST /{db}/_local_docs/queries`` endpoints. Also, a new endpoint
> >   ``POST /{db}/_design/{ddoc}/_view/{view}/queries`` has been introduced
> to replace
> >   the ``?queries`` parameter formerly provided for making multiple
> queries to a view.
> >   The old ``?queries`` parameter *is now deprecated and will be removed
> in a future
> >   release of CouchDB.*
>
> I’m not super-excited about following through on either of those
> deprecations :) I feel like the `stale` one in particular is still in heavy
> use. The queries one is probably OK.
>
> On the FDB topic, I believe the transaction logs are configured with the
> equivalent of delayed_commits=false (thus ensuring the durability of a
> transaction), while the storage servers only periodically fsync data that
> they pull off the transaction logs. I don’t think the fsync behavior can be
> configured using the normal configuration file, but if you go digging into
> the codebase there’s a Knobs file that has all kinds of settings that
> shouldn’t be messed with by mere mortals :) I wouldn’t be surprised if some
> of the durability settings can be tweaked there.
>
> Adam
>
> > On Sep 4, 2019, at 9:13 PM, Joan Touzet  wrote:
> >
> >
> >
> > On 2019-09-04 20:53, Adam Kocoloski wrote:
> >> Great list, Joan, thanks. I created a handful of GitHub issues for the
> first two sections and tossed them in the “Proposed for 3.x” column. I also
> submitted a PR to address one of them :)
> >
> > Cheers! I've also retitled that column "3.0 Release Tasks" since I think
> > that's how we're treating it. If it turns out anything needs to be
> > bumped to 3.x, we can create a new column for that.
> >
> >> Out of that list of already-deprecated functionality the only one that
> gives me pause is the delayed_commits one. We haven’t talked about it in
> years, and we ship a safe default. I’d be a little concerned about breaking
> folks who intentionally switched it on with full knowledge of the tradeoffs.
> >
> > Another option would be to just remove the setting from default.ini and
> > the documentation.
> >
> > Does FDB have anything similar?
> >
> > -Joan
> >
> >> Adam
> >>
> >>> On Sep 4, 2019, at 5:44 PM, Johs Ensby  wrote:
> >>>
> >>> Much appreciated, Joan
> >>> You're a hero
> >>> Johs
> >>>
>  On 4 Sep 2019, at 23:37, Joan Touzet  wrote:
> 
>  Hey Adam,
> 
> > When it comes to deprecating and/or removing functionality, I feel
> like I don’t know exactly where we stand today. We have occasionally
> described some of the CouchApp functionality as already being deprecated,
> but I’m having trouble finding any official record of that in our
> documentation.
>  Thanks for re-opening the deprecation discussion. I've reviewed [1]
> and
>  provide the following summary tables (Markdown format).
> 
>  **NOTE**: This is /not/ the vote for deprecation, nor a formal
>  announcement of such. This is a starting point for discussion. A vote
>  still needs to happen for this to move forward. Anything already
>  deprecated in 2.0 can be removed in 3.0 without a formal vote, but
> it'd
>  be nice if it got mentioned on the dev@ list before the PR lands on
>  master, please.
> 
>  As I'm going to be travelling for most of the rest of September, I'd
>  prefer if someone else (like Adam or Deni) can help drive this
> discussion.
> 
>  Once there is consensus from the community on these lists, we should
>  close #1534 and split it into 3 new tickets based on the tables below
>  (excepting the features already removed in 2.x).
> 
> > I guess let’s start with: does anyone believe we are in a position
> to be eliminating previously-deprecated functionality in 3.0?
> 
>  Yes, for the items in the 2nd table below, absolutely.
> 
>  -Joan "turning the tables" Touzet
> 
> 
>  
> 
> 
>  # Recently removed features in 2.x
> 
>

Re: Proposed deprecations / removals (was: Re: Getting started on CouchDB 3.0, and an introduction)

2019-09-04 Thread Joan Touzet 



On 2019-09-04 20:53, Adam Kocoloski wrote:
> Great list, Joan, thanks. I created a handful of GitHub issues for the first 
> two sections and tossed them in the “Proposed for 3.x” column. I also 
> submitted a PR to address one of them :)

Cheers! I've also retitled that column "3.0 Release Tasks" since I think
that's how we're treating it. If it turns out anything needs to be
bumped to 3.x, we can create a new column for that.

> Out of that list of already-deprecated functionality the only one that gives 
> me pause is the delayed_commits one. We haven’t talked about it in years, and 
> we ship a safe default. I’d be a little concerned about breaking folks who 
> intentionally switched it on with full knowledge of the tradeoffs.

Another option would be to just remove the setting from default.ini and
the documentation.

Does FDB have anything similar?

-Joan

> Adam
> 
>> On Sep 4, 2019, at 5:44 PM, Johs Ensby  wrote:
>>
>> Much appreciated, Joan
>> You're a hero
>> Johs
>>
>>> On 4 Sep 2019, at 23:37, Joan Touzet  wrote:
>>>
>>> Hey Adam,
>>>
 When it comes to deprecating and/or removing functionality, I feel like I 
 don’t know exactly where we stand today. We have occasionally described 
 some of the CouchApp functionality as already being deprecated, but I’m 
 having trouble finding any official record of that in our documentation.
>>> Thanks for re-opening the deprecation discussion. I've reviewed [1] and
>>> provide the following summary tables (Markdown format).
>>>
>>> **NOTE**: This is /not/ the vote for deprecation, nor a formal
>>> announcement of such. This is a starting point for discussion. A vote
>>> still needs to happen for this to move forward. Anything already
>>> deprecated in 2.0 can be removed in 3.0 without a formal vote, but it'd
>>> be nice if it got mentioned on the dev@ list before the PR lands on
>>> master, please.
>>>
>>> As I'm going to be travelling for most of the rest of September, I'd
>>> prefer if someone else (like Adam or Deni) can help drive this discussion.
>>>
>>> Once there is consensus from the community on these lists, we should
>>> close #1534 and split it into 3 new tickets based on the tables below
>>> (excepting the features already removed in 2.x).
>>>
 I guess let’s start with: does anyone believe we are in a position to be 
 eliminating previously-deprecated functionality in 3.0?
>>>
>>> Yes, for the items in the 2nd table below, absolutely.
>>>
>>> -Joan "turning the tables" Touzet
>>>
>>>
>>> 
>>>
>>>
>>> # Recently removed features in 2.x
>>>
>>> **Feature/Endpoint**| **Links**
>>> |
>>> update_notifications| [10]
>>> ini-file based query servers| [11]
>>> ini-file based HTTP global handlers | [11]
>>> OS daemons  | [11],[12]
>>> vhost redirects/global handlers | [11],[12]
>>> couch_httpd_proxy   | [11],[12]
>>>
>>> *NOTE*: Some of these still have lingering bits in the documentation
>>>   that need a final cleanup pass before 3.0 should be released.
>>>
>>> 
>>>
>>> # Already deprecated items, to be removed in 3.0
>>>
>>> **Feature/Endpoint**| **Links**
>>> |
>>> some duplicate dbinfo size fields   | [2],[3]
>>> delayed_commits | [4]
>>> port 5986   | [5],[6]
>>> `/{db}/_external/*` | [7],[8]
>>> view-based changes (code remnants)  | [17],[18],[19],[20]
>>>
>>> 
>>>
>>> # Proposed deprecations for 3.0, not rebuilt/removed in 4.0
>>>
>>>  **Feature/Endpoint**   |**Replaced by**   | **Links**
>>> --|--|---
>>> `/{db}/{ddoc}/_show/*`| App server/rev proxy | †
>>> `/{db}/{ddoc}/_list/*`| App server/rev proxy | †
>>> virtual hosts [24]| haproxy, multitenant | [25]
>>> `/{db}/{ddoc}/_rewrite/*` | App server/rev proxy | [26]
>>>
>>> †: getRow() makes embedding a new, efficient JS engine impossible since
>>> getRow() does not give up thread execution control; an entirely new
>>> approach would need to be constructed, breaking backward compatibility
>>> at the very least. (There are additional challenges.)
>>>
>>> 
>>>
>>> # Likely will remain unchanged through 4.0
>>>
>>>  **Feature/Endpoint**  |**Improved by**
>>> -|--
>>> VDU (validatefun()) [13] | [14],[15]
>>> update handlers (updatefun) [16] | [14],[15]
>>> JS engine [21]   | [22],[23]
>>> system DB special handling   | [27]
>>>
>>> *NOTE*: The last table may grow as limitations imposed by FDB are better
>>>   understood.
>>>
>>> 
>>>
>>> # References
>>>
>>> [1]: https://github.com/apache/couchdb/issues/1534
>>> [2]:
>>> https://docs.couchdb.org/en/stable/api/database/common.html?highlight=disk-size#get--db
>>> [3]:

Re: Proposed deprecations / removals (was: Re: Getting started on CouchDB 3.0, and an introduction)

2019-09-04 Thread Adam Kocoloski 
Great list, Joan, thanks. I created a handful of GitHub issues for the first 
two sections and tossed them in the “Proposed for 3.x” column. I also submitted 
a PR to address one of them :)

Out of that list of already-deprecated functionality the only one that gives me 
pause is the delayed_commits one. We haven’t talked about it in years, and we 
ship a safe default. I’d be a little concerned about breaking folks who 
intentionally switched it on with full knowledge of the tradeoffs.

Adam

> On Sep 4, 2019, at 5:44 PM, Johs Ensby  wrote:
> 
> Much appreciated, Joan
> You're a hero
> Johs
> 
>> On 4 Sep 2019, at 23:37, Joan Touzet  wrote:
>> 
>> Hey Adam,
>> 
>>> When it comes to deprecating and/or removing functionality, I feel like I 
>>> don’t know exactly where we stand today. We have occasionally described 
>>> some of the CouchApp functionality as already being deprecated, but I’m 
>>> having trouble finding any official record of that in our documentation.
>> Thanks for re-opening the deprecation discussion. I've reviewed [1] and
>> provide the following summary tables (Markdown format).
>> 
>> **NOTE**: This is /not/ the vote for deprecation, nor a formal
>> announcement of such. This is a starting point for discussion. A vote
>> still needs to happen for this to move forward. Anything already
>> deprecated in 2.0 can be removed in 3.0 without a formal vote, but it'd
>> be nice if it got mentioned on the dev@ list before the PR lands on
>> master, please.
>> 
>> As I'm going to be travelling for most of the rest of September, I'd
>> prefer if someone else (like Adam or Deni) can help drive this discussion.
>> 
>> Once there is consensus from the community on these lists, we should
>> close #1534 and split it into 3 new tickets based on the tables below
>> (excepting the features already removed in 2.x).
>> 
>>> I guess let’s start with: does anyone believe we are in a position to be 
>>> eliminating previously-deprecated functionality in 3.0?
>> 
>> Yes, for the items in the 2nd table below, absolutely.
>> 
>> -Joan "turning the tables" Touzet
>> 
>> 
>> 
>> 
>> 
>> # Recently removed features in 2.x
>> 
>> **Feature/Endpoint**| **Links**
>> |
>> update_notifications| [10]
>> ini-file based query servers| [11]
>> ini-file based HTTP global handlers | [11]
>> OS daemons  | [11],[12]
>> vhost redirects/global handlers | [11],[12]
>> couch_httpd_proxy   | [11],[12]
>> 
>> *NOTE*: Some of these still have lingering bits in the documentation
>>   that need a final cleanup pass before 3.0 should be released.
>> 
>> 
>> 
>> # Already deprecated items, to be removed in 3.0
>> 
>> **Feature/Endpoint**| **Links**
>> |
>> some duplicate dbinfo size fields   | [2],[3]
>> delayed_commits | [4]
>> port 5986   | [5],[6]
>> `/{db}/_external/*` | [7],[8]
>> view-based changes (code remnants)  | [17],[18],[19],[20]
>> 
>> 
>> 
>> # Proposed deprecations for 3.0, not rebuilt/removed in 4.0
>> 
>>  **Feature/Endpoint**   |**Replaced by**   | **Links**
>> --|--|---
>> `/{db}/{ddoc}/_show/*`| App server/rev proxy | †
>> `/{db}/{ddoc}/_list/*`| App server/rev proxy | †
>> virtual hosts [24]| haproxy, multitenant | [25]
>> `/{db}/{ddoc}/_rewrite/*` | App server/rev proxy | [26]
>> 
>> †: getRow() makes embedding a new, efficient JS engine impossible since
>> getRow() does not give up thread execution control; an entirely new
>> approach would need to be constructed, breaking backward compatibility
>> at the very least. (There are additional challenges.)
>> 
>> 
>> 
>> # Likely will remain unchanged through 4.0
>> 
>>  **Feature/Endpoint**  |**Improved by**
>> -|--
>> VDU (validatefun()) [13] | [14],[15]
>> update handlers (updatefun) [16] | [14],[15]
>> JS engine [21]   | [22],[23]
>> system DB special handling   | [27]
>> 
>> *NOTE*: The last table may grow as limitations imposed by FDB are better
>>   understood.
>> 
>> 
>> 
>> # References
>> 
>> [1]: https://github.com/apache/couchdb/issues/1534
>> [2]:
>> https://docs.couchdb.org/en/stable/api/database/common.html?highlight=disk-size#get--db
>> [3]: https://github.com/apache/couchdb/pull/2163
>> [4]:
>> https://github.com/apache/couchdb/blob/103a0624f309ea0d796176a55eb5faea68f26047/test/javascript/tests/delayed_commits.js#L16
>> [5]: https://github.com/apache/couchdb/issues/1523
>> [6]: https://github.com/apache/couchdb/pull/2092
>> [7]: https://github.com/apache/couchdb/pull/1330
>> [8]: https://docs.couchdb.org/en/stable/whatsnew/2.2.html
>> [10]: https://github.com/apache/couchdb/pull/1476
>> [11]:

Re: Proposed deprecations / removals (was: Re: Getting started on CouchDB 3.0, and an introduction)

2019-09-04 Thread Johs Ensby 
Much appreciated, Joan
You're a hero
Johs

> On 4 Sep 2019, at 23:37, Joan Touzet  wrote:
> 
> Hey Adam,
> 
>> When it comes to deprecating and/or removing functionality, I feel like I 
>> don’t know exactly where we stand today. We have occasionally described some 
>> of the CouchApp functionality as already being deprecated, but I’m having 
>> trouble finding any official record of that in our documentation.
> Thanks for re-opening the deprecation discussion. I've reviewed [1] and
> provide the following summary tables (Markdown format).
> 
> **NOTE**: This is /not/ the vote for deprecation, nor a formal
> announcement of such. This is a starting point for discussion. A vote
> still needs to happen for this to move forward. Anything already
> deprecated in 2.0 can be removed in 3.0 without a formal vote, but it'd
> be nice if it got mentioned on the dev@ list before the PR lands on
> master, please.
> 
> As I'm going to be travelling for most of the rest of September, I'd
> prefer if someone else (like Adam or Deni) can help drive this discussion.
> 
> Once there is consensus from the community on these lists, we should
> close #1534 and split it into 3 new tickets based on the tables below
> (excepting the features already removed in 2.x).
> 
>> I guess let’s start with: does anyone believe we are in a position to be 
>> eliminating previously-deprecated functionality in 3.0?
> 
> Yes, for the items in the 2nd table below, absolutely.
> 
> -Joan "turning the tables" Touzet
> 
> 
> 
> 
> 
> # Recently removed features in 2.x
> 
> **Feature/Endpoint**| **Links**
> |
> update_notifications| [10]
> ini-file based query servers| [11]
> ini-file based HTTP global handlers | [11]
> OS daemons  | [11],[12]
> vhost redirects/global handlers | [11],[12]
> couch_httpd_proxy   | [11],[12]
> 
> *NOTE*: Some of these still have lingering bits in the documentation
>that need a final cleanup pass before 3.0 should be released.
> 
> 
> 
> # Already deprecated items, to be removed in 3.0
> 
> **Feature/Endpoint**| **Links**
> |
> some duplicate dbinfo size fields   | [2],[3]
> delayed_commits | [4]
> port 5986   | [5],[6]
> `/{db}/_external/*` | [7],[8]
> view-based changes (code remnants)  | [17],[18],[19],[20]
> 
> 
> 
> # Proposed deprecations for 3.0, not rebuilt/removed in 4.0
> 
>   **Feature/Endpoint**   |**Replaced by**   | **Links**
> --|--|---
> `/{db}/{ddoc}/_show/*`| App server/rev proxy | †
> `/{db}/{ddoc}/_list/*`| App server/rev proxy | †
> virtual hosts [24]| haproxy, multitenant | [25]
> `/{db}/{ddoc}/_rewrite/*` | App server/rev proxy | [26]
> 
> †: getRow() makes embedding a new, efficient JS engine impossible since
> getRow() does not give up thread execution control; an entirely new
> approach would need to be constructed, breaking backward compatibility
> at the very least. (There are additional challenges.)
> 
> 
> 
> # Likely will remain unchanged through 4.0
> 
>   **Feature/Endpoint**  |**Improved by**
> -|--
> VDU (validatefun()) [13] | [14],[15]
> update handlers (updatefun) [16] | [14],[15]
> JS engine [21]   | [22],[23]
> system DB special handling   | [27]
> 
> *NOTE*: The last table may grow as limitations imposed by FDB are better
>understood.
> 
> 
> 
> # References
> 
> [1]: https://github.com/apache/couchdb/issues/1534
> [2]:
> https://docs.couchdb.org/en/stable/api/database/common.html?highlight=disk-size#get--db
> [3]: https://github.com/apache/couchdb/pull/2163
> [4]:
> https://github.com/apache/couchdb/blob/103a0624f309ea0d796176a55eb5faea68f26047/test/javascript/tests/delayed_commits.js#L16
> [5]: https://github.com/apache/couchdb/issues/1523
> [6]: https://github.com/apache/couchdb/pull/2092
> [7]: https://github.com/apache/couchdb/pull/1330
> [8]: https://docs.couchdb.org/en/stable/whatsnew/2.2.html
> [10]: https://github.com/apache/couchdb/pull/1476
> [11]: https://docs.couchdb.org/en/stable/whatsnew/2.3.html
> [12]: https://github.com/apache/couchdb/pull/1602
> [13]: https://docs.couchdb.org/en/stable/ddocs/ddocs.html#vdufun
> [14]: https://github.com/apache/couchdb/issues/1554
> [15]: https://github.com/apache/couchdb/pull/1898
> [16]: https://docs.couchdb.org/en/stable/ddocs/ddocs.html#update-functions
> [17]: https://github.com/apache/couchdb/issues/592
> [18]: https://github.com/apache/couchdb/issues/831
> [19]:
> https://lists.apache.org/thread.html/516793df0c1913c045441d0ff78339f307e2aff517d9223da44edd9e@%3Cdev.couchdb.apache.org%3E
> [20]:
>