-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ES6 in view functions #4175
Comments
@diachedelic I think it could be related to the transformation that happens in https://github.com/apache/couchdb/blob/main/share/server/60/rewrite_fun.js There, we parse js functions into an AST, patch them to turn "function(...) {...}" into a proper JS syntax (CouchDB global "function(...) {...}" it turns out are not valid JS), and then back to a js source string. It could be that the parsers we use esprima and escodegen don't handle ES6 syntax. That's just a guess so far, I haven't validated it yet. A related issue perhaps as well: #2372 |
Sorry, I have mischaracterised this error. It appears to actually be a load-sensitive, intermittent failure that happened to correspond perfectly with me switching |
Ah no worries, thanks for reaching out. There was an issue related to performance regression with custom reduces with later (> 1.8.5. spidermonkey) #3517. Something to be aware when upgrading from older CouchDB instances. |
I was not using custom reducers, but the error certainly occurred more often when I used |
That could be, it's hard to saw without more details metrics. That parser/emitter piece of code might have to work harder some newer code constructs like |
Is there a way to profile CouchDB's execution of JavaScript? It would be interesting to know where the bottleneck is. |
couchjs processes are run as a pool so it maybe possible to compare the CPU usage of those couchjs processes before and after. Or run a benchmark building a view on both setups and see which takes longer. With the 2.x/3.x versions, setting the Q sharding factor could help parallelize view builds, so with Q=16 if you have a large database, all 16 shard ranges (and 3 copies if you have a 3 node cluster) will build in parallel. |
Thanks, that's good to know. If I run into unavoidable performance problems I will give it a shot. Something else I would like to know is why the view functions need to be transpiled for newer SpiderMonkeys, but not for 1.8.5. Is there a discussion anywhere I can read more about this? |
Oh, I found #2345, the PR for upgrading to SpiderMonkey 60 from 1.8.5. Something I still don't understand is why a view function like |
Oh, I found https://issues.apache.org/jira/browse/COUCHDB-1643. |
I recently upgraded from CouchDB 1.6.1 to 3.2.2, and took a moment to clean up my view functions. In the following view function, all I did was change the
var
to alet
:As a result, GET requests to this view began responding with an error:
Reverting to the
var
solves the issue. I have tested this both with a native MacOS installation and the official Docker image, with identical results.Calling GET /_node/_local/_versions gives:
From what I could discern, SpiderMonkey v78 was used in Firefox v78, which certainly supported the
let
statement. So shouldn'tlet
be supported in view functions? Have I missed something?The text was updated successfully, but these errors were encountered: