Re: [PROPOSAL] Deprecate global functions in query server
> this.emit(doc.key)
Normally this.propName points to the ddoc property, if any. So better
this._emit since properties with _ are prohibited for docs.
ermouth
2015-12-12 16:03 GMT+03:00 Jan Lehnardt <j...@apache.org>:
> I’m in favour of doing something like this.
>
> How about adding them to the function in question?
>
> So
>
> function(doc) {
> emit(doc.key)
> }
>
> would become
>
> function(doc) {
> this.emit(doc.key)
> }
>
> +1. no need to mess with the function signature.
> +2. no clunky here’s-a-bunch-functions object that isn’t already there.
> +3. most upgrades are string replace away.
>
> -1. overloading this could be seen as clunky in itself.
> -2. still doesn’t solve that `function() {}` is not valid JavaScript and
> doesn’t work in newer SpiderMonkeys or other engines. But that might be out
> of scope.
>
> Best
> Jan
> --
>
>
>
> > On 02 Dec 2015, at 14:06, Alexander Shorin <kxe...@gmail.com> wrote:
> >
> > While I like require(...) way to handle this issue, I will allow
> > myself to disagree with the emit argument in function signature.
> > Because if we upgrade SM to get generators feature then we can throw
> > away emit at all. Map functions are perfect generators and Python
> > query server experience showed that this is great idea.
> > SM / JS support upgrade is unavoidable, so let's look a little bit far
> > in the future to now fix same things twice (;
> >
> > --
> > ,,,^..^,,,
> >
> >
> > On Wed, Dec 2, 2015 at 4:01 PM, Garren Smith <gar...@apache.org> wrote:
> >> Ok you make good points and I wasn’t aware of all these functions
> http://docs.couchdb.org/en/1.6.1/query-server/javascript.html <
> http://docs.couchdb.org/en/1.6.1/query-server/javascript.html>
> >> I’m going to do one more bike shed and then I will leave it up to you
> and other people who actually want to implement this.
> >> For the case of map reduce, I would go with a function call like I said
> before
> >>
> >> function (doc, emit) {
> >>
> >> }
> >>
> >> Then for all our other helpers I would make them available through a
> require. This in my mind makes it similar to node.js or to a browser if you
> use browserify, web pack, requirejs etc
> >> So a full example would be
> >>
> >> function (doc, emit) {
> >> var isArray = require(‘helpers’).isArray;
> >> var allHelpers = require(‘helpers’);
> >>
> >>
> >> }
> >>
> >> That is my 2 cents worth.
> >>
> >> Cheers
> >> Garren
> >>
> >>> On 02 Dec 2015, at 2:42 PM, Alexander Shorin <kxe...@gmail.com> wrote:
> >>>
> >>> Hi Garren,
> >>>
> >>> On Wed, Dec 2, 2015 at 3:35 PM, Garren Smith <gar...@apache.org>
> wrote:
> >>>>
> >>>> This is an interesting idea. I think passing the emit function in is
> a good idea and might make somethings easier in PouchDB. I would rather a
> map function looked something like this
> >>>>
> >>>> function (doc, emit) {
> >>>>
> >>>> }
> >>>
> >>> That's nice, but won't work: map function has access to a lot of other
> >>> global functions we provide, so you'll end with signature of 7
> >>> arguments. I don't think there is any reason to fix this problem by a
> >>> half. Just fix all globals or no one.
> >>>
> >>>> I don’t like the idea of passing a userCtx object. That feels overly
> bulky. Things like JSON/require are global variables in Node.js or the
> browser so my feeling is to follow their lead on those.
> >>>
> >>> ctx referenced not to userCtx, but a generic context object that hold
> >>> all the global function and objects we provide now. These are listed
> >>> in reference on documentation. May be we can find a better name to not
> >>> cause confusion. funcs? env? Suggestions welcome (:
> >>>
> >>> --
> >>> ,,,^..^,,,
> >>
>
>
Re: [PROPOSAL] Chainable requests
> is not like multiple lines of code in a server side .asp php or node
program
> it is more like "ask for this, and depending on the answer,
> ask for this" like a "request tree"
Actually, that _is_ like asp, php or node program :) As for php guys
approach is nearly native, sync program code runs inbetween DB requests.
As for node.js guys it also could be understood in native paradigm: think
couchapp functions are kinda middleware in request processing chain, and
each middleware function can determine next step.
Somehow like express.js maybe, but in express you call next(args) when in
CouchDB you just return {path:"...", body:"args"}. Also in node your
middleware can be async, but in CouchDB it should be sync.
ermouth
2015-11-26 5:11 GMT+03:00 Johs Ensby <j...@b2w.com>:
> Ermouth,
>
> > On 25. nov. 2015, at 18.18, ermouth <ermo...@gmail.com> wrote:
> > chunked response and reduce approach
>
>
> I think both modes are valuable, conceptually we end up with 3 modes of
> respons
> Technically it makes sense to describe as server response.
>
> I am trying to think of how we want to spin this to the new developers
>
> I would recommend that we name the feature as seen from the front-end
> developer
>
> - single request
> - chained request
> - progressive load
>
> The 3rd being a variant of chained request not accumulating but spitting
> output into the client for as long as it takes
>
> "Single reqest" is the normal thing, but what we see as one of the painful
> limitations of Couch
> "Chained request" is the new thing that is not like multiple lines of code
> in a server side .asp php or node program, it is more like "ask for this,
> and depending on the answer, ask for this" like a "rewuest tree"
> "Progressive load" is a super way to improve performance, it is writing
> for UX, "what the user needs right away is... then and eventually
> she/he will be looking for .. if a link in the first chucks has been
> clicked yet"
>
> johs
Re: serving html pages built from multiple lists or shows
> If you could find the time to do a screen recording of what you just described https://www.youtube.com/watch?v=_FoI2An3JRc Bit messy since it‘s impromptu ermouth
Caching results of _list functions
Since JS rewrites landed in 2.0, and I use JS rewrites heavily, I discover some tricks with the new feature time to time. Despite I use patched 1.6.1 with js rewrites, tricks are suitable for at least single node 2.0 as well. JS rewrites function runs in the context of a query server instance. QS instance is a Spidermonkey process with 64Mb of RAM by default. It‘s single threaded. Actually, seems that all query server functions of one particular design doc are executed inside one dedicated Spidermonkey instance. It means they all share global context (also it means they share one thread). Ddoc global context persists until Spidermonkey process is restarted. It happens when SM instance crashes (runs out of RAM quota, unrecoverable error happens etc), or when underlying design doc is changed. It means _list function can cache results of rendering into RAM, and _rewrite function can later quickly respond with cached version, skipping redirect to heavy map/list. Cache container is just JS closure, instantiated/accessed using built-in require(). Unlike _list, JS rewrite function does not receive req.info, it would be too slow to tap DB on each request. It means we can not invalidate cache on local sequence change (DB update) – rewrite function just does not know DB was updated. However we can use timestamp-based caching, even several seconds TTL of cache entries is enough to reduce average response time significantly (say, order of magnitude). I‘ve tested approach a little and found it very promising. Since this dirty hack is possible with _list fns only, without js rewrites, may be someone already employs it? Or at least tried? ermouth
Changing replication filter on the fly
There is known feature of continuous filtered replication: until
replication restarts, filter function is frozen.
It means you can start continuous filtered replication using _replicator
DB, then change (or even remove) filter function – and have your sync still
running with an old filter.
To ensure your changed filter can take control, you must explicitly remove
and re-create _replicator doc. It means stop/restart of sync flow and bit
too complex.
There exist another way.
Imagine we have filter fn, distributing docs between nodes according to
some topology. Let‘s say our topology is just a branch of a filter design
doc, and accessible from inside filter fn as this.topology property.
So our ddoc looks like:
{_id:"_design/topo",
topology:{node1:["org1","org2"],node2:["org3"]},
filter:"function(doc, req){ /* whatever */}"}
What happens when we change topology property and save ddoc? Our already
running filter function is not hot-swapped, however it immediately receives
its updated parent ddoc as an input.
So filter fn takes new topology and persists it into this.topology
property. One step:
if (doc._id=="_design/topo") this.topology = doc.topology;
All subsequent changes will be processed with updated topology settings,
and we achieved this without touching _replication DB.
Works like a charm.
ermouth
Re: Couchapp experience in 2016
> using more CouchDB design documents simultanously is not fast enogh? It‘s not. There are 2 basic considerations: a) node is faster as a compiler and generates code, that runs faster, b) we can avoid excessive serialize/parse calls between OTP and SM, which are both CPU and IO hungry for large branchy docs. Although we add several more layers here, and they add latency, which diminish our performance boost. So I‘m not sure if 5x rps and bandwidth per core achievable, gonna play with it a little. ermouth
Re: CouchDB 2.0 and "Intuitive HTTP/JSON API and designed for Reliability" for couchapps
Couch 2.0 fails to process rewritten paths with ampersands (more than 1 param in query). Afaik (however I have not tested) this issue is fixed in 2.1. Although I‘m not sure it is the reason. To note: I plan to uncover a preview of new query server on Monday, as a full replacement for lists, shows, rewrites, updates and so on. With SMS, emails and all missing stuff. So stay tuned. ermouth 2017-05-23 13:47 GMT+03:00 Johs Ensby <j...@b2w.com>: > Hi, > we have been using Couch 1.6 with a patch for the rewrite function, but I > wanted to see how 2.0 in single node mode was doing these past two days. > The test case was a rather big web site with a few databases holding a few > thousand documents, images, PDF attachments. It is performing very well on > Couch 1.6 > > Moving it from the cloud instance offline to a local Mac was as > straigthforward as replication can be and with a few tweeks to the > configration the site popped up on my iMac with all bells and whistles. > That is, a few records did not replicate from Couch 1.6 on Ubuntu/AWS to my > local Mac. > > But what quickly turned out to be a bigger problem was that attachments > did not load into the browser reliably. > CSS files and images would sometimes load, somtimes not. Normally the CSS > files would load once and cache in the browser, but that did not prevent > pages from loaded occationally as if the css file was missing (not with a > 404, just show a red GET in the inspector without an error code). > I seem to remember that there was a discussion about Etags in 2.0, but > dont know if this is the issue here. > Strange things like the images coming up instead of the requested images > also happened. > Safari was a lot worse than Chrome. > > Could anyone tell me if these are known bugs that are fixed in 2.1? > > Best regards, > johs > > >
Re: Photon, 90% progress
Thank you, Harald! Actually, it‘s not a couchapp from thin air, Photon was created inside browser using couchapps. Photon never existed as source files, only source docs. So entire couchapp (db hosted app) technology is powerful, its hidden potential is still nearly untouched, as I see it. ermouth 2017-09-15 11:41 GMT+03:00 Harald Kisch <haraldki...@gmail.com>: > Thank You, ermouth! > For me this is the best editor for CouchDB and the best way to edit large > JSON structures. > It is also the simplest way to install a CouchApp, simply by pasting your > JSON code into a design document and click save. > Photon also shows how powerful this kind of application is. > > Great work! > > harald > > On Thu, Sep 14, 2017 at 10:14 PM, ermouth <ermo...@gmail.com> wrote: > > > Now 100% Futon features coverage. Recorded a screencast about Photon > > features https://www.youtube.com/watch?v=MHc6tozNhWU > > > > ermouth > > > > 2017-09-08 7:02 GMT+03:00 ermouth <ermo...@gmail.com>: > > > > > Think Photon is ready for more wide testing, https://github.com/ > > > ermouth/couch-photon > > > > > > As for now, 0.2.830, all original Futon features are covered, except > two: > > > creating sync tasks and view compaction on per ddoc basis. > > > > > > Most original Futon features were bit improved in Photon. Also Photon > > > includes several features not present in Futon, see boasting in PS. > > > > > > The sweetest new feature is instant update. Right navbar button, > which > > > opens About tab, now allows to check for updates from AWS S3 CDN (no > > > logging there). It means Photon can be kept fresh in literally two > > clicks. > > > > > > Bug reports and suggestions are highly welcomed. > > > > > > ermouth > > > > > > PS. Photon boasting: > > > > > > * In-app tabs, restored on reload; > > > * Valid state-to-URL# reflection, so most states have unique URLs; > > > * Group actions for DBs and docs; > > > * JSON for config, so group updates for config keys or even sections; > > > * View navigation starting from a specific key; > > > * You can choose to purge or retain doc content on deletion; > > > * Doc revision navigation includes conflicts if any. > > > > > > > > > -- > -- > > Dipl.-Inf. Harald R. Kisch > > Falkenstraße 19C > 81541 München > Germany > > Mobil DE: +49 (0) 176 56 58 58 38 > > Skype: harald.kisch > Mail: haraldki...@gmail.com >
Re: Photon, 90% progress
Thank you, Aurélien! > and a convincing demo I appreciate your sense of humor, but I afraid my awful English is not too convincing ) ermouth
Re: Photon, 90% progress
Thank you, Giovanni! BTW, tested Photon at Smileupps, seems to work. However, I missed one important detail: if the DB list tab is constantly open and visible, Photon makes a request every several seconds, polling tasks. Not so good for pay-for-request services. Gonna fix it.
Re: Photon, 90% progress
Now 100% Futon features coverage. Recorded a screencast about Photon features https://www.youtube.com/watch?v=MHc6tozNhWU ermouth 2017-09-08 7:02 GMT+03:00 ermouth <ermo...@gmail.com>: > Think Photon is ready for more wide testing, https://github.com/ > ermouth/couch-photon > > As for now, 0.2.830, all original Futon features are covered, except two: > creating sync tasks and view compaction on per ddoc basis. > > Most original Futon features were bit improved in Photon. Also Photon > includes several features not present in Futon, see boasting in PS. > > The sweetest new feature is instant update. Right navbar button, which > opens About tab, now allows to check for updates from AWS S3 CDN (no > logging there). It means Photon can be kept fresh in literally two clicks. > > Bug reports and suggestions are highly welcomed. > > ermouth > > PS. Photon boasting: > > * In-app tabs, restored on reload; > * Valid state-to-URL# reflection, so most states have unique URLs; > * Group actions for DBs and docs; > * JSON for config, so group updates for config keys or even sections; > * View navigation starting from a specific key; > * You can choose to purge or retain doc content on deletion; > * Doc revision navigation includes conflicts if any. >
Re: Fauxton, Futon and licensing obstacles
Progress so far: very early public beta https://github.com/ermouth/couch-photon About 80% ready I hope, not tested in 2.x at all. ermouth 2017-08-30 21:45 GMT+03:00 ermouth <ermo...@gmail.com>: > Work in progress, watch video https://youtu.be/lBVdIPZhDc4 to see current > state. > > Right now codename Photon is a json with footprint well below 1.5Mb. > > ermouth > >
Re: Fauxton, Futon and licensing obstacles
Work in progress, watch video https://youtu.be/lBVdIPZhDc4 to see current state. Right now codename Photon is a json with footprint well below 1.5Mb. ermouth
Re: Fauxton, Futon and licensing obstacles
> Opening design documents seems not working Fixed. ermouth
Re: Fauxton, Futon and licensing obstacles
> The ones I miss now are: mango queries and attachments access. Attachments management is underway. As for mango. I will be happy if you could record a short screencast with several examples how you use mango in Fauxton. Query examples, expected output etc. We do not use mango at all, so I just don‘t have enough details on mango-related UX. So I‘m asking for hints ) ermouth
Photon, 90% progress
Think Photon is ready for more wide testing, https://github.com/ermouth/couch-photon As for now, 0.2.830, all original Futon features are covered, except two: creating sync tasks and view compaction on per ddoc basis. Most original Futon features were bit improved in Photon. Also Photon includes several features not present in Futon, see boasting in PS. The sweetest new feature is instant update. Right navbar button, which opens About tab, now allows to check for updates from AWS S3 CDN (no logging there). It means Photon can be kept fresh in literally two clicks. Bug reports and suggestions are highly welcomed. ermouth PS. Photon boasting: * In-app tabs, restored on reload; * Valid state-to-URL# reflection, so most states have unique URLs; * Group actions for DBs and docs; * JSON for config, so group updates for config keys or even sections; * View navigation starting from a specific key; * You can choose to purge or retain doc content on deletion; * Doc revision navigation includes conflicts if any.
Re: Fauxton, Futon and licensing obstacles
Opening ddocs indeed does not work for some configs (smileupps ie), this issue will be fixed soon. Encoding _design%2F <=> _design/, you know. ermouth 2017-09-06 13:24 GMT+03:00 Giovanni Lenzi <g.le...@smileupps.com>: > Great tool ermouth, > > seems very fast and tabs greatly simplify administration tasks. > > Opening design documents seems not working... Are you planning to include > different editor for them? > > Thanks for work and great idea! > --Giovanni > > 2017-09-06 8:40 GMT+02:00 Johs. E <j...@b2w.com>: > > > Congratulations with fantastic progress, ermouth! > > Will test tonight. > > johs > > > > > On 6 Sep 2017, at 08:37, ermouth <ermo...@gmail.com> wrote: > > > > > > Progress so far: very early public beta > > > https://github.com/ermouth/couch-photon > > > > > > About 80% ready I hope, not tested in 2.x at all. > > > > > > ermouth > > > > > > 2017-08-30 21:45 GMT+03:00 ermouth <ermo...@gmail.com>: > > > > > >> Work in progress, watch video https://youtu.be/lBVdIPZhDc4 to see > > current > > >> state. > > >> > > >> Right now codename Photon is a json with footprint well below 1.5Mb. > > >> > > >> ermouth > > >> > > >> > > > > >
Re: Fauxton, Futon and licensing obstacles
No CloudWall runtime, it would be too limiting in this particular case. ermouth 2017-08-24 8:08 GMT+03:00 Johs Ensby <j...@b2w.com>: > ermouth, > you are doing this as a cloudwell app with the cloudwall runtime > supporting the single ddoc app, right? > Johs > > On 23 Aug 2017, at 21:56, ermouth <ermo...@gmail.com> wrote: > > > > Good idea, however I gonna start with CouchDB ) > > > > I‘ve recordered 5min screencast about JSON editor for CN Photon > > https://youtu.be/OQ_YJ0EZQjE > > > > ermouth > > > > 2017-08-23 9:10 GMT+03:00 Martin Broerse <martin.broe...@gmail.com>: > > > >> Perhaps also include pouchdb databases in Photon. You would need to type > >> the database name you like to connect to because there is no index > >> implemented. See https://github.com/w3c/IndexedDB/issues/31 . Caching > the > >> pouchdb database names would be be a nice feature for Photon. If Photo > is > >> build in Ember we can use https://github.com/pouchdb- > community/ember-pouch > >> to connect to the pouchdb databases. > >> > >> On Tue, Aug 22, 2017 at 5:09 PM, ermouth <ermo...@gmail.com> wrote: > >> > >>> Several sketches http://jquerymy.com/kod/photon1.pdf > >>> > >>> ermouth > >>> > >>> 2017-08-20 15:07 GMT+03:00 ermouth <ermo...@gmail.com>: > >>> > >>>> Seems that Fauxton experiencing some troubles with React unfriendly > >>>> licensing. It‘s a pity taking in account CouchDB 2 moved to fairly > >> stable > >>>> state, and Fauxton itself received a lot of great improvements since > >> last > >>>> year. > >>>> > >>>> However, in new circumstances, what do you think about re-creating > >>>> something like Futon+ (for Couch 2) as a single ddoc? So you copy > >>>> open-sourced ddoc json to any DB, run index.html attachment from the > >>> ddoc – > >>>> and you‘re in. > >>>> > >>>> Basically, the idea is to re-create Futon-like app as a couchapp. > >>>> > >>>> If an idea is reasonable, is it reasonable to make the process openly > >>>> funded in some way, to make it more rapid and controllable? > >>>> > >>>> ermouth > >>>> > >>> > >> > >
Fauxton, Futon and licensing obstacles
Seems that Fauxton experiencing some troubles with React unfriendly licensing. It‘s a pity taking in account CouchDB 2 moved to fairly stable state, and Fauxton itself received a lot of great improvements since last year. However, in new circumstances, what do you think about re-creating something like Futon+ (for Couch 2) as a single ddoc? So you copy open-sourced ddoc json to any DB, run index.html attachment from the ddoc – and you‘re in. Basically, the idea is to re-create Futon-like app as a couchapp. If an idea is reasonable, is it reasonable to make the process openly funded in some way, to make it more rapid and controllable? ermouth
1.6.1: interim patch
Upgrading to 1.7.1 is important since CVE-2017-12635 is a serious hole.
However, there exist an interim way. Below design doc just rejects .roles
dupes. You can check it putting into any other db first and trying to put
new doc like {"roles":[],"roles":[1]}. If validator is ok, rejection reason
is ‘You can't hack roles’.
{
"_id": "_design/X12635",
"language": "erlang",
"validate_doc_update": "fun ({NewDoc}, OldDoc, UserCtx, SecObj)->\n\t%%
Covers CVE-2017-12635\n\tRoles = proplists:lookup_all(<<\"roles\">>,
NewDoc),\n\tcase length(Roles) < 2 of\n\t\ttrue -> ok;\n\t\tfalse ->
throw({[{<<\"forbidden\">>, <<\"You can’t hack roles,
sorry\">>}]})\n\tend,\n\t1\nend."
}
Since ability to save json with double entry of .roles array is a key of
the 12635 vulnerability, the ddoc seems to fix it, if put into /_users
bucket.
Nothing comes without price: you need to set native_query_servers / erlang
= {couch_native_process, start_link, []} in DB config. Since enabling
erlang might affect security, each case should be carefully assessed.
Although this trick is acceptable if you postponing upgrade to 1.7.1 for
reasons not under your control, I highly recommend upgrade as soon as
possible.
ermouth
CloudWall 2.2
Hello all, happy to announce CloudWall 2.2, http://cloudwall.me. It‘s a toy in-browser noBackend OS, which uses PouchDB/CouchDB instead of file system. New features: * CW, both as a compiled design doc and as sources, now installs using replication. * All apps and documentation were upgraded. * Added latest Photon, Ddoc Lab and Inliner apps, with sources. CW 2.2 can run a) from static hosting, b) as a couchapp bound to a dedicated domain, c) as a couch-hosted app, directly from index.html attach. CloudWall is built by itself, so sources are good example how to build couch-hosted app of such complexity using nothing but browser. ermouth
Re: IBM Cloudant - Support for Virtual Hosts Ending December 4, 2017
Martin! You may use smileupps.com, max version is 1.6.0. Also you may use ami-29ecda5e AWS EC2 image (Ireland), which is 1.6.1 with 2.x-style JS rewrites. However, taking in account last CouchDB critical vulnerability, you should be very careful with your _users DB and protect it from changing by any user except admins. ermouth
Re: Call for "Must-fix" issues
Single-node install without shards. ermouth 2018-07-05 11:20 GMT+03:00 ermouth : > Proxy authorization which is also in docs, but absent in 2.x. > > ermouth > > 2018-07-05 10:10 GMT+03:00 Johs Ensby : > >> This thread reach out to CouchDB 1.x users to generate a list of >> "must-fix" issues that is preventing users to upgrade to the latest >> version of CouchDB. >> >> It is in response to Joan's comment below regarding the >> non-technical proposal to make a project decision to terminate >> official Apache support for CouchDB 1.x. >> >> > On 5 Jul 2018, at 06:31, Joan Touzet wrote: >> > >> > As for things in 2.x that are "must fix" before people can upgrade, I >> > too would like to see pull requests for those. Once again, your help is >> > most welcome in this - both in identifying a definitive list of those >> > must-fix issues, as well as code towards fixing them. If you'd like >> > to help with this important work, please start a new thread. >> >> >> >> Mine is CouchDB as a proxy. >> The feature described here is not working in 2.1.1 >> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy >> >> Johs >> > >
Re: Call for "Must-fix" issues
Proxy authorization which is also in docs, but absent in 2.x. ermouth 2018-07-05 10:10 GMT+03:00 Johs Ensby : > This thread reach out to CouchDB 1.x users to generate a list of > "must-fix" issues that is preventing users to upgrade to the latest > version of CouchDB. > > It is in response to Joan's comment below regarding the > non-technical proposal to make a project decision to terminate > official Apache support for CouchDB 1.x. > > > On 5 Jul 2018, at 06:31, Joan Touzet wrote: > > > > As for things in 2.x that are "must fix" before people can upgrade, I > > too would like to see pull requests for those. Once again, your help is > > most welcome in this - both in identifying a definitive list of those > > must-fix issues, as well as code towards fixing them. If you'd like > > to help with this important work, please start a new thread. > > > > Mine is CouchDB as a proxy. > The feature described here is not working in 2.1.1 > http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy > > Johs >
Re: Call for "Must-fix" issues
> convenience of one file on disk per database is gone, but is there anything else There were serious issues with single node shards (or whatever those pieces were) during upgrade from 2.1.0 to 2.1.1. I read only brief report, but remember it completely broken tests in some bizzare way, like inability to save docs with particular _id ranges. > could you unveil this secret, please? There’s nothing secret here, theoretically you have to insert two oneliners into chttpd_auth and then rebuild. Obvious task for end user ) -export([proxy_authentication_handler/1]). and proxy_authentication_handler(Req) -> couch_httpd_auth:proxy_authentication_handler(Req, chttpd_auth_cache). But as I can recollect it also finally broke things in some bizzare way. ermouth 2018-07-05 11:59 GMT+03:00 Johs Ensby : > >> > >> Proxy authorization which is also in docs, but absent in 2.x. > > > > it is not absent, just not exposed by default. You can configure to > enable it (it’s just not documented ;) > > Hi Jan, > could you unveil this secret, please? > johs > > > > > On 5 Jul 2018, at 10:53, Jan Lehnardt wrote: > > > > > > > >> On 5. Jul 2018, at 10:20, ermouth wrote: > >> > >> Proxy authorization which is also in docs, but absent in 2.x. > > > > it is not absent, just not exposed by default. You can configure to > enable it (it’s just not documented ;) > > > >> Single-node install without shards. > > > > Both the /_setup_cluster endpoint and the Mac binaries already set q=1 & > n = 1 on setup. Everyone else can configure it. > > > > Best > > Jan > > — > > > >> > >> ermouth > >> > >> 2018-07-05 10:10 GMT+03:00 Johs Ensby : > >> > >>> This thread reach out to CouchDB 1.x users to generate a list of > >>> "must-fix" issues that is preventing users to upgrade to the latest > >>> version of CouchDB. > >>> > >>> It is in response to Joan's comment below regarding the > >>> non-technical proposal to make a project decision to terminate > >>> official Apache support for CouchDB 1.x. > >>> > >>>> On 5 Jul 2018, at 06:31, Joan Touzet wrote: > >>>> > >>>> As for things in 2.x that are "must fix" before people can upgrade, I > >>>> too would like to see pull requests for those. Once again, your help > is > >>>> most welcome in this - both in identifying a definitive list of those > >>>> must-fix issues, as well as code towards fixing them. If you'd like > >>>> to help with this important work, please start a new thread. > >>> > >>> > >>> > >>> Mine is CouchDB as a proxy. > >>> The feature described here is not working in 2.1.1 > >>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy > >>> > >>> Johs > >>> > > > > -- > > Professional Support for Apache CouchDB: > > https://neighbourhood.ie/couchdb-support/ > > > > ……… > 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 > >
Re: Call for "Must-fix" issues
> This is rather inaccurate > A regrettable regression, > but only a config issue Well enough to block upgrade. Anyway, as we see now those non-technical issues of different nature improve the number of requests for paid support. I wouldn’t account this fact as popularity, as Joan did, however hope it at least sweetens regrets. ermouth
On 1.x deprecation
TLDR; Please vote -1 at @dev thread ‘[PROPOSAL] Officially deprecate CouchDB 1.x.’ All arguments of the proposal are of no basis. --- Hope, we all read deprecation statement from Joan. She provided one reason directly, also several were coined in indirect way. 1. “No one is maintaining the 1.x.x branches of CouchDB anymore” Probably that’s because they just do not need daily maintenance. 2. “Issues stack up on the tracker with no response.” Ok, lets count. Right now couchdb github repo has 133 issues open, 11 of them have 1.x tag. 21 of those 133 are marked with red bug tag, but none of them with 1.x. So seems 1.x have no serious bugs, but 2.x have a pile. How about “no response”? All 1.x issues have at least one. 33% of non-1.x issues have zero answers. So I’d say if there exist a stack up, it’s not related to 1.x, it’s more about 2.x. 3. “Having to patch 1.x as well as 2.x slows down the security team's ability to push releases quickly out the door” First, this game is two-sided. Probably, necessaty to fix not so adopted version slowed down the team from releasing very minor upgrade for very stable version widely used in production. Probably, back-porting of not widely adopted 2.x features into 1.7 also slowed process down. Or, probably, there were no slowdown at all? As I know, that ‘slow down’ was never complained. 4. “By focusing on what we do best - supporting 2.x” As I showed earlier it’s looks incomparably easier to support 1.x than 2.x. As I can see from numbers, supporting 2.x issues have already taken all focus. It happened about 1.5 years ago I’d say. Ok, have anyone ever complained? Today I consulted a guy from BY by phone, yesterday from IN – also privately. Classic reasonable CouchDB guys seem to be pretty well aware they won’t have a lot of help from official support anyway. They do not need bug fixes, they want to discuss use strategies, solution details, they want hints and opinions how to improve things that already works fine. So 1.x doesn’t blur developers’ focus, unless developers start demnding granny’s blood. Granny is still pretty healthy. 5. “I’m definitely seeing more people on 2.x these days than 1.x, *significantly* more - both from our informal support channels as well as through GitHub Issues and requests for paid support” This argument is very strange. It looks like someone already have a lot of 2.x tickets and want even more. Sorry, but I don’t see how it reflects real users distribution, I only see that 2.x is more buggy and though sells paid support better. --- So, as I see all above arguments for deprecation have no relation to real accountable state of things, unless I suppose the goal is paid support. Honestly, I can’t believe in it. Then why deprecate? The deprecation notice by itself breaks reputation of 1.6/1.7, which is for now waaay more reliable than 2.x. At least 1.6 doesn’t bite unexpectedly. I hope keeping things as is for about a year is well enough to fix most visible 2.x issues, and then – long live 1.x. Unfortunately I’m not subscribed to @dev and can’t reply into past proposal thread even if get subscribed now. So if you feel my arguments are reasonable, I ask you to cast ‘-1’ under that proposal. Thank you. ermouth
Re: On 1.x deprecation
> Approximately how many 1.x nodes to you have in production now? > What is your estimated total no of users on these? Sorry, can’t disclose this kind of info publicly. All I can say I have zero nodes with 2.x in prod, despite we analyzed can we migrate several times. We can’t, 2.x just does not fit for production, which is well proved by Joan words about paid support requests, github issues and my own tests. ermouth
Re: Call for "Must-fix" issues
I’m sorry to say, but: — Fauxton is unable to show doc attachments list in any modern browser on http connection — Fauxton is still unable to make “Back” button working in _config section — Fauxton doesn’t work on ~20% of browsers, polyfills for missing browser features is still an unknown term for Fauxton — Fauxton is still unable to validate at least JSON syntax on typing, I’m not saying about Mango syntax — Fauxton is still all about making as much UI noise as possible, sacrificing data density I discovered all this in first 2 minutes after install – just to check have anything changed. You said tables? I’m sorry to say, but tables is the least problem. Anyway, Fauxton is absolutely on par with CouchDB 2 in terms of product quality. An you enforce people to migrate on _this_? Are you kidding? And, to prevent known spells: sorry, no bug reports and no pull requests, all above problems were already reported. ermouth
