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&update=false``, and the old
>   ``stale=update_after`` behaviour is equivalent to 
> ``stable=true&update=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 <woh...@apache.org> 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 <j...@b2w.com> wrote:
>>> 
>>> Much appreciated, Joan
>>> You're a hero
>>> Johs
>>> 
>>>> On 4 Sep 2019, at 23:37, Joan Touzet <woh...@apache.org> 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]:
>>>> http://docs.couchdb.org/en/stable/api/database/changes.html?highlight=selector#selector
>>>> [21]: https://github.com/apache/couchdb/issues/1513
>>>> [22]: https://github.com/apache/couchdb/issues/1875
>>>> [23]: https://github.com/apache/couchdb/issues/1884
>>>> [24]: https://docs.couchdb.org/en/stable/config/http.html#virtual-hosts
>>>> [25]: https://github.com/apache/couchdb/issues/1539
>>>> [26]:
>>>> https://docs.couchdb.org/en/stable/api/ddoc/rewrites.html#api-ddoc-rewrite
>>>> [27]: https://github.com/apache/couchdb/issues/1534
>>>> 
>>> 
>>> ………………………………………
>>> Johannes Ensby
>>> 
>>> 
>>> Business to Web AS
>>> Tollbugata 8, N- 0152 Oslo, Norway
>>> +47 611 00 006 (mobile)
>>> +47 611 00 700 (switchboard)
>>> j...@b2w.com
>>> www.linkedin.com/in/ensby
>>> www.b2w.com
>>> 
>> 
> 

Reply via email to