[jira] [Commented] (COUCHDB-1302) Fix couchjs
[
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13121748#comment-13121748
]
Paul Joseph Davis commented on COUCHDB-1302:
From Benoit on the ML:
if we do that it would imply the release of a major version since the change
is major. I'm +1 to introduce correct behaviour in trunk rather than trying
to hack arouind our own insanity.
I think its a good idea to revert this on 1.1.x as it could break user code for
no good reason. Though 1.1.x will have the ability to use newer SpiderMonkey's,
they'll have to deal with upgrading their JS code.
What we do about 1.2.x and trunk I'm less certain. On the one hand, we could
save some people some effort. On the other hand, we'd also be breaking things
for people that use helper functions that haven't upgraded to 1.8.5 or w/e
version of SM introduces this.
Bottom line is that there's no good answer other than making sure we note it in
our NEWS files, and on the website and also try and document it in error
messages.
Quite an unfortunate situation that I see no good answer to.
Fix couchjs
---
Key: COUCHDB-1302
URL: https://issues.apache.org/jira/browse/COUCHDB-1302
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Affects Versions: 1.1.1, 1.2, 1.3
Reporter: Paul Joseph Davis
Priority: Blocker
Figure out why some spidermonkeys have an error when doing:
eval(function(){})
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: CouchDB 1.1.1
All, Paul Davis has researched the issue and it seems intractable. I would like to remove 1.8.5 support from 1.1.1. It was not present in 1.1.0 so will not be (officially) missed. The place for a breaking change of this magnitude is 1.2, not a minor bug fix release. Thoughts? B. On 5 October 2011 18:25, Paul Davis paul.joseph.da...@gmail.com wrote: Yes, its release blocking. On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson rnew...@apache.org wrote: All, I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to include everything that was missing (Sidenote: Can we all keep this file up to date when commit bugfixes or add features?). I'd appreciate everyone giving it a look over before I start to build the release artifact. I believe there's an outstanding issue (not present in JIRA) around javascript function evaluation? Can someone confirm that it's release blocking? Thanks, B.
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson rnew...@apache.org wrote: All, Paul Davis has researched the issue and it seems intractable. I would like to remove 1.8.5 support from 1.1.1. It was not present in 1.1.0 so will not be (officially) missed. The place for a breaking change of this magnitude is 1.2, not a minor bug fix release. Thoughts? B. +1 on removing the paren hack for sure. Not sure about removing 1.8.5 support completely. On the one hand, it would prevent breakage because people couldn't link against the breaking SM. On the other hand, it prevents people from linking against 1.8.5 which means it won't build on Ubuntu 11.x. Unless someone comes up with a magic option I'd say put it to an informal vote so that I can blame someone else. On 5 October 2011 18:25, Paul Davis paul.joseph.da...@gmail.com wrote: Yes, its release blocking. On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson rnew...@apache.org wrote: All, I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to include everything that was missing (Sidenote: Can we all keep this file up to date when commit bugfixes or add features?). I'd appreciate everyone giving it a look over before I start to build the release artifact. I believe there's an outstanding issue (not present in JIRA) around javascript function evaluation? Can someone confirm that it's release blocking? Thanks, B.
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 10:25, Paul Davis paul.joseph.da...@gmail.com wrote: +1 on removing the paren hack for sure. Can you elaborate on what the paren hack is? Not sure about removing 1.8.5 support completely. On the one hand, it would prevent breakage because people couldn't link against the breaking SM. On the other hand, it prevents people from linking against 1.8.5 which means it won't build on Ubuntu 11.x. That seems problematic. With my packager hat on, I would also prefer if 1.8.5 support came sooner rather than later. Cheers, Dirkjan
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 10:25 AM, Paul Davis paul.joseph.da...@gmail.com wrote: On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson rnew...@apache.org wrote: All, Paul Davis has researched the issue and it seems intractable. I would like to remove 1.8.5 support from 1.1.1. It was not present in 1.1.0 so will not be (officially) missed. The place for a breaking change of this magnitude is 1.2, not a minor bug fix release. Thoughts? B. +1 on removing the paren hack for sure. Not sure about removing 1.8.5 support completely. On the one hand, it would prevent breakage because people couldn't link against the breaking SM. On the other hand, it prevents people from linking against 1.8.5 which means it won't build on Ubuntu 11.x. Is this really a problem with 1.8.5 ? How do you explain then that I have to remove this changes to have refuge working with it then? https://github.com/refuge/refuge/commit/481bd6623ccfc8895eacf8a1528bffa5efa4ad47#apps/couch/share/server/util.js Refuge is only working with 1.8.5. - benoît
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 3:29 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Thu, Oct 6, 2011 at 10:25, Paul Davis paul.joseph.da...@gmail.com wrote:
+1 on removing the paren hack for sure.
Can you elaborate on what the paren hack is?
Unfotunately, SM 1.8.5 breaks the ability to evaluate anonymous
functions at global scope. So all CouchDB code examples are
effectively broken. The fix is to wrap the function in parentheses
to trick the parser into returning the anonymous function. Ie,
Given a standard CouchDB map function like:
function(doc) {
if(doc.my_type) emit(doc.my_type, 1);
}
The fix is to do:
(function(doc) {
if(doc.my_type) emit(doc.my_type, 1);
})
However, if people are using helper functions at global scope, it
turns into this:
(var f = function() {return 2;};
function(doc) {
if(doc.my_type) emit(doc.my_type, f());
})
Which is an error on all versions of SpiderMonkey.
Basically, SpiderMonkey got stricter about following the spec by hard
coding a check for the exact type of anonymous function declarations
that CouchDB has relied on (unknowingly in my case) for years.
Not sure about removing 1.8.5 support completely. On the one hand, it
would prevent breakage because people couldn't link against the
breaking SM. On the other hand, it prevents people from linking
against 1.8.5 which means it won't build on Ubuntu 11.x.
That seems problematic. With my packager hat on, I would also prefer
if 1.8.5 support came sooner rather than later.
Cheers,
Dirkjan
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 3:51 AM, Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Oct 6, 2011 at 10:25 AM, Paul Davis paul.joseph.da...@gmail.com
wrote:
On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson rnew...@apache.org wrote:
All,
Paul Davis has researched the issue and it seems intractable.
I would like to remove 1.8.5 support from 1.1.1. It was not present in
1.1.0 so will not be (officially) missed.
The place for a breaking change of this magnitude is 1.2, not a minor
bug fix release.
Thoughts?
B.
+1 on removing the paren hack for sure.
Not sure about removing 1.8.5 support completely. On the one hand, it
would prevent breakage because people couldn't link against the
breaking SM. On the other hand, it prevents people from linking
against 1.8.5 which means it won't build on Ubuntu 11.x.
Is this really a problem with 1.8.5 ? How do you explain then that I
have to remove this changes to have refuge working with it then?
https://github.com/refuge/refuge/commit/481bd6623ccfc8895eacf8a1528bffa5efa4ad47#apps/couch/share/server/util.js
Refuge is only working with 1.8.5.
- benoît
Things I know for certain:
This fails in the js shell from the 1.8.5 tarball:
eval(function(){})
It also fails on the package in Debian that is supposed to be
SpiderMonkey 1.8.5. It also fails on a checkout of the mercurial
repository with hash 959c1e6bdb11.
Fact of the matter, SpiderMonkey distribution is notorious in its
avoidance of anything resembling a versioning scheme that we can use
to refer to API/ABI compatibility across platforms. Not that it
matters as it's apparently a fix, so at the end of the day new
SpiderMonkey breaks code that has worked for years.
By enabling the linkage (for which, if code were proper, things would
work) we introduce a non-obvious new behavior error.
If we *intentionally disable* 1.8.5 linking, then we avoid introducing
errors subtly into code that has always worked if someone tries to
upgrade SpiderMonkey to a version that breaks old code. That said, we
also limit the ability of CouchDB to run easily on OS's that include
newer SpiderMonkeys.
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 10:30, Robert Newson rnew...@apache.org wrote: Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and then focus on getting 1.2 out with 1.8.5 support (and BREAKING CHANGES). If we're optimistic about getting 1.2 out soonish, getting 1.1.1 out without 1.8.5 support seems fine. Cheers, Dirkjan
Re: CouchDB 1.1.1
While I agree on the sentiment, I don't think it's part of the decision. Even if 1.2 is months away, I don't think we can introduce such a break in a minor point release. I'm working on the patch to remove this, can some other devs please chime in soon with their opinions/votes? B. On 6 October 2011 10:34, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Thu, Oct 6, 2011 at 10:30, Robert Newson rnew...@apache.org wrote: Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and then focus on getting 1.2 out with 1.8.5 support (and BREAKING CHANGES). If we're optimistic about getting 1.2 out soonish, getting 1.1.1 out without 1.8.5 support seems fine. Cheers, Dirkjan
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 11:42 AM, Robert Newson rnew...@apache.org wrote: While I agree on the sentiment, I don't think it's part of the decision. Even if 1.2 is months away, I don't think we can introduce such a break in a minor point release. I'm working on the patch to remove this, can some other devs please chime in soon with their opinions/votes? B. already said but +1 for that. - benoit
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 11:06 AM, Paul Davis paul.joseph.da...@gmail.com wrote:
On Thu, Oct 6, 2011 at 3:51 AM, Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Oct 6, 2011 at 10:25 AM, Paul Davis paul.joseph.da...@gmail.com
wrote:
On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson rnew...@apache.org wrote:
All,
Paul Davis has researched the issue and it seems intractable.
I would like to remove 1.8.5 support from 1.1.1. It was not present in
1.1.0 so will not be (officially) missed.
The place for a breaking change of this magnitude is 1.2, not a minor
bug fix release.
Thoughts?
B.
+1 on removing the paren hack for sure.
Not sure about removing 1.8.5 support completely. On the one hand, it
would prevent breakage because people couldn't link against the
breaking SM. On the other hand, it prevents people from linking
against 1.8.5 which means it won't build on Ubuntu 11.x.
Is this really a problem with 1.8.5 ? How do you explain then that I
have to remove this changes to have refuge working with it then?
https://github.com/refuge/refuge/commit/481bd6623ccfc8895eacf8a1528bffa5efa4ad47#apps/couch/share/server/util.js
Refuge is only working with 1.8.5.
- benoît
Things I know for certain:
This fails in the js shell from the 1.8.5 tarball:
eval(function(){})
It also fails on the package in Debian that is supposed to be
SpiderMonkey 1.8.5. It also fails on a checkout of the mercurial
repository with hash 959c1e6bdb11.
Fact of the matter, SpiderMonkey distribution is notorious in its
avoidance of anything resembling a versioning scheme that we can use
to refer to API/ABI compatibility across platforms. Not that it
matters as it's apparently a fix, so at the end of the day new
SpiderMonkey breaks code that has worked for years.
By enabling the linkage (for which, if code were proper, things would
work) we introduce a non-obvious new behavior error.
If we *intentionally disable* 1.8.5 linking, then we avoid introducing
errors subtly into code that has always worked if someone tries to
upgrade SpiderMonkey to a version that breaks old code. That said, we
also limit the ability of CouchDB to run easily on OS's that include
newer SpiderMonkeys.
The odd thing is that refuge is using the archive downloadable on
mozilla website.
Anyway that doesn't change anything to the fact that we should correct
our js I agree. I would be for a 2.0 then, like noah.
- benoit
Re: CouchDB 1.1.1
On Oct 6, 2011, at 10:30 , Robert Newson wrote: There is no build of 1.1.1 on Ubuntu 11.x that will work as well as 1.1.0, so I think it's correct that it cannot build under those conditions. Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and then focus on getting 1.2 out with 1.8.5 support (and BREAKING CHANGES). I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x. +1 Cheers Jan -- B. On 6 October 2011 09:25, Paul Davis paul.joseph.da...@gmail.com wrote: On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson rnew...@apache.org wrote: All, Paul Davis has researched the issue and it seems intractable. I would like to remove 1.8.5 support from 1.1.1. It was not present in 1.1.0 so will not be (officially) missed. The place for a breaking change of this magnitude is 1.2, not a minor bug fix release. Thoughts? B. +1 on removing the paren hack for sure. Not sure about removing 1.8.5 support completely. On the one hand, it would prevent breakage because people couldn't link against the breaking SM. On the other hand, it prevents people from linking against 1.8.5 which means it won't build on Ubuntu 11.x. Unless someone comes up with a magic option I'd say put it to an informal vote so that I can blame someone else. On 5 October 2011 18:25, Paul Davis paul.joseph.da...@gmail.com wrote: Yes, its release blocking. On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson rnew...@apache.org wrote: All, I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to include everything that was missing (Sidenote: Can we all keep this file up to date when commit bugfixes or add features?). I'd appreciate everyone giving it a look over before I start to build the release artifact. I believe there's an outstanding issue (not present in JIRA) around javascript function evaluation? Can someone confirm that it's release blocking? Thanks, B.
Re: CouchDB 1.1.1
Thanks all, I've pushed the change to 1.1.x. make check and futon all pass; review would still be nice. :) I simply reverted the two commits. B. On 6 October 2011 12:02, Jan Lehnardt j...@apache.org wrote: On Oct 6, 2011, at 10:30 , Robert Newson wrote: There is no build of 1.1.1 on Ubuntu 11.x that will work as well as 1.1.0, so I think it's correct that it cannot build under those conditions. Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and then focus on getting 1.2 out with 1.8.5 support (and BREAKING CHANGES). I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x. +1 Cheers Jan -- B. On 6 October 2011 09:25, Paul Davis paul.joseph.da...@gmail.com wrote: On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson rnew...@apache.org wrote: All, Paul Davis has researched the issue and it seems intractable. I would like to remove 1.8.5 support from 1.1.1. It was not present in 1.1.0 so will not be (officially) missed. The place for a breaking change of this magnitude is 1.2, not a minor bug fix release. Thoughts? B. +1 on removing the paren hack for sure. Not sure about removing 1.8.5 support completely. On the one hand, it would prevent breakage because people couldn't link against the breaking SM. On the other hand, it prevents people from linking against 1.8.5 which means it won't build on Ubuntu 11.x. Unless someone comes up with a magic option I'd say put it to an informal vote so that I can blame someone else. On 5 October 2011 18:25, Paul Davis paul.joseph.da...@gmail.com wrote: Yes, its release blocking. On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson rnew...@apache.org wrote: All, I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to include everything that was missing (Sidenote: Can we all keep this file up to date when commit bugfixes or add features?). I'd appreciate everyone giving it a look over before I start to build the release artifact. I believe there's an outstanding issue (not present in JIRA) around javascript function evaluation? Can someone confirm that it's release blocking? Thanks, B.
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13121871#comment-13121871
]
Riyad Kalla commented on COUCHDB-1302:
--
Now is the perfect opportunity to make this change, once 1.2/2.0 goes out the
door it likely couldn't be safely addressed again until 3.0 and the uptake in
CouchDB (from what I see at least) seems to be on the rapid rise.
Making this change in 1.2/2.0 becomes an education issue, so maybe some
questions around how to be *really* helpful explaining the situation to the
user, e.g. errors in the server log when the problem is encountered and exactly
how to work around it pointing at a Wiki page with clarification explaining
why; maybe warnings during startup when the server does a quick scan for the
issue (that can be disabled if the user knows they have a good setup);
Sure it will be painful, but trying to monkey-patch this until 3.0 (or beyond)
will be much more painful and have a lot more negative impact by that time.
I like Jason's suggestion of some quick-patch tool that might ship with the
install that attempts the fix automatically or at least gives the users enough
tools and help/information so as to get them from Point A to B as quickly as
possible.
Fix couchjs
---
Key: COUCHDB-1302
URL: https://issues.apache.org/jira/browse/COUCHDB-1302
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Affects Versions: 1.1.1, 1.2, 1.3
Reporter: Paul Joseph Davis
Priority: Blocker
Figure out why some spidermonkeys have an error when doing:
eval(function(){})
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1303) Add a _bulk_update handler similar to _update but for bulk document changes
[ https://issues.apache.org/jira/browse/COUCHDB-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13121989#comment-13121989 ] Benoit Chesneau commented on COUCHDB-1303: -- posted on dev@ , copied here. I would really prefer to sit down a little and start to rethink the couchapp engine. Restful means imo that on a particular resource we could react on each actions (here HTTP verbs). Instead we did the same error Rails did by having a resource per actions or so. Bulk updates would be another hack around this so I'm -1 on such features. New ticket about what i would like to design is coming along. Add a _bulk_update handler similar to _update but for bulk document changes --- Key: COUCHDB-1303 URL: https://issues.apache.org/jira/browse/COUCHDB-1303 Project: CouchDB Issue Type: New Feature Reporter: Benjamin Young Labels: api, update_request_handler _update handlers are great (and getting better!) for building RESTful API's inside CouchDB. One limitation I found tonight is that _update can only do a single document at a time. If the API I'm building needs to update multiple docs (in a similar fashion to _bulk_docs), then an outside proxy script is required. It would be ideal to have a _bulk_update handler to allow for the same functionality as _update, but with the ability to insert multiple documents at once. Perhaps the current _update handler API could be extended to support multiple IDs/documents, but a separate API endpoint would be seem reasonable if needed. Thanks for considering this idea. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1303) Add a _bulk_update handler similar to _update but for bulk document changes
[
https://issues.apache.org/jira/browse/COUCHDB-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122013#comment-13122013
]
Benjamin Young commented on COUCHDB-1303:
-
I do agree that the more the more RESTful thing to do would actually be
allowed to POST to the /db/ URL with a specific mimetype that designated that
one was sending a representation containing several documents to be added
(which of course could use it's own ticket). However, as we allow end users to
extend CouchDB's functionality with CouchApp additions (which is fabulous!),
we need to offer them as much power as possible so this can move out of being a
toy (for some) into being a viable stack.
The develoepr generated additions (such as _update handlers) can live wherever
they need to in the CouchDB URL space (all of them are currently under
_design/{app}), as long as they are wrap-able by the URL rewriter, the
developer can make their own API's and vhost them wherever they'd like.
That's the goal of this request. I agree that the whole CouchApp
approach/concept could use a fresh approach, but I'm not sure it's a good
reason to stall what we have moving now.
I look forward to seeing your CouchApp-related proposals, but I'd prefer this
(and any other) idea be measured on its merits relative to the current
code--not potential rewrites. There are likely other reasons this might be bad,
but because we should start over isn't one of them. :)
Add a _bulk_update handler similar to _update but for bulk document changes
---
Key: COUCHDB-1303
URL: https://issues.apache.org/jira/browse/COUCHDB-1303
Project: CouchDB
Issue Type: New Feature
Reporter: Benjamin Young
Labels: api, update_request_handler
_update handlers are great (and getting better!) for building RESTful API's
inside CouchDB. One limitation I found tonight is that _update can only do a
single document at a time. If the API I'm building needs to update multiple
docs (in a similar fashion to _bulk_docs), then an outside proxy script is
required. It would be ideal to have a _bulk_update handler to allow for the
same functionality as _update, but with the ability to insert multiple
documents at once.
Perhaps the current _update handler API could be extended to support multiple
IDs/documents, but a separate API endpoint would be seem reasonable if needed.
Thanks for considering this idea.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: CouchDB 1.1.1
If there are no objections, I'm going to build the first 1.1.1 candidate in the morning and start a new thread for the release. B. On 6 October 2011 12:05, Robert Newson rnew...@apache.org wrote: Thanks all, I've pushed the change to 1.1.x. make check and futon all pass; review would still be nice. :) I simply reverted the two commits. B. On 6 October 2011 12:02, Jan Lehnardt j...@apache.org wrote: On Oct 6, 2011, at 10:30 , Robert Newson wrote: There is no build of 1.1.1 on Ubuntu 11.x that will work as well as 1.1.0, so I think it's correct that it cannot build under those conditions. Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and then focus on getting 1.2 out with 1.8.5 support (and BREAKING CHANGES). I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x. +1 Cheers Jan -- B. On 6 October 2011 09:25, Paul Davis paul.joseph.da...@gmail.com wrote: On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson rnew...@apache.org wrote: All, Paul Davis has researched the issue and it seems intractable. I would like to remove 1.8.5 support from 1.1.1. It was not present in 1.1.0 so will not be (officially) missed. The place for a breaking change of this magnitude is 1.2, not a minor bug fix release. Thoughts? B. +1 on removing the paren hack for sure. Not sure about removing 1.8.5 support completely. On the one hand, it would prevent breakage because people couldn't link against the breaking SM. On the other hand, it prevents people from linking against 1.8.5 which means it won't build on Ubuntu 11.x. Unless someone comes up with a magic option I'd say put it to an informal vote so that I can blame someone else. On 5 October 2011 18:25, Paul Davis paul.joseph.da...@gmail.com wrote: Yes, its release blocking. On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson rnew...@apache.org wrote: All, I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to include everything that was missing (Sidenote: Can we all keep this file up to date when commit bugfixes or add features?). I'd appreciate everyone giving it a look over before I start to build the release artifact. I believe there's an outstanding issue (not present in JIRA) around javascript function evaluation? Can someone confirm that it's release blocking? Thanks, B.
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 6:23 PM, Robert Newson rnew...@apache.org wrote: If there are no objections, I'm going to build the first 1.1.1 candidate in the morning and start a new thread for the release. As pointed out in 2 other related threads, we have some compilation warnings about functions that will no longer exist in OTP R15 (to be released by the end of this year): /opt/r14b03/bin/erlc +debug_info oauth_http.erl ./oauth_http.erl:13: Warning: http:request/4 is deprecated and will be removed in R15B; use httpc:request/4 /opt/r14b03/bin/erlc +debug_info oauth_plaintext.erl /opt/r14b03/bin/erlc +debug_info oauth_rsa_sha1.erl ./oauth_rsa_sha1.erl:9: Warning: public_key:pem_to_der/1: deprecated (will be removed in R15A); use file:read_file/1 and public_key:pem_decode/1 ./oauth_rsa_sha1.erl:10: Warning: public_key:decode_private_key/1 is deprecated and will be removed in R15A; use public_key:pem_entry_decode/1 ./oauth_rsa_sha1.erl:22: Warning: public_key:pem_to_der/1: deprecated (will be removed in R15A); use file:read_file/1 and public_key:pem_decode/1 /opt/r14b03/bin/erlc +debug_info oauth_unix.erl The ones regarding public_key concern me, as it will break the OAuth authentication handler. I see 2 solutions: 1) upgrade erlang-oauth to the same version we have in trunk/1.2.x (doesn't produce these warnings) 2) modify the erlang-oauth in 1.1.x and use try catches where the catch would call the equivalent versions in R14/R15 (these new functions don't exist in R13B03 for example) Naturally, I would prefer 1) The warnings about http:request can be ignored I think, as in Couch we don't use any codepath that will execute the deprecated function B. On 6 October 2011 12:05, Robert Newson rnew...@apache.org wrote: Thanks all, I've pushed the change to 1.1.x. make check and futon all pass; review would still be nice. :) I simply reverted the two commits. B. On 6 October 2011 12:02, Jan Lehnardt j...@apache.org wrote: On Oct 6, 2011, at 10:30 , Robert Newson wrote: There is no build of 1.1.1 on Ubuntu 11.x that will work as well as 1.1.0, so I think it's correct that it cannot build under those conditions. Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and then focus on getting 1.2 out with 1.8.5 support (and BREAKING CHANGES). I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x. +1 Cheers Jan -- B. On 6 October 2011 09:25, Paul Davis paul.joseph.da...@gmail.com wrote: On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson rnew...@apache.org wrote: All, Paul Davis has researched the issue and it seems intractable. I would like to remove 1.8.5 support from 1.1.1. It was not present in 1.1.0 so will not be (officially) missed. The place for a breaking change of this magnitude is 1.2, not a minor bug fix release. Thoughts? B. +1 on removing the paren hack for sure. Not sure about removing 1.8.5 support completely. On the one hand, it would prevent breakage because people couldn't link against the breaking SM. On the other hand, it prevents people from linking against 1.8.5 which means it won't build on Ubuntu 11.x. Unless someone comes up with a magic option I'd say put it to an informal vote so that I can blame someone else. On 5 October 2011 18:25, Paul Davis paul.joseph.da...@gmail.com wrote: Yes, its release blocking. On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson rnew...@apache.org wrote: All, I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to include everything that was missing (Sidenote: Can we all keep this file up to date when commit bugfixes or add features?). I'd appreciate everyone giving it a look over before I start to build the release artifact. I believe there's an outstanding issue (not present in JIRA) around javascript function evaluation? Can someone confirm that it's release blocking? Thanks, B. -- Filipe David Manana, Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
Re: CouchDB 1.1.1
does the newer erlang-oauth break anything? On 6 October 2011 18:52, Filipe David Manana fdman...@apache.org wrote: On Thu, Oct 6, 2011 at 6:23 PM, Robert Newson rnew...@apache.org wrote: If there are no objections, I'm going to build the first 1.1.1 candidate in the morning and start a new thread for the release. As pointed out in 2 other related threads, we have some compilation warnings about functions that will no longer exist in OTP R15 (to be released by the end of this year): /opt/r14b03/bin/erlc +debug_info oauth_http.erl ./oauth_http.erl:13: Warning: http:request/4 is deprecated and will be removed in R15B; use httpc:request/4 /opt/r14b03/bin/erlc +debug_info oauth_plaintext.erl /opt/r14b03/bin/erlc +debug_info oauth_rsa_sha1.erl ./oauth_rsa_sha1.erl:9: Warning: public_key:pem_to_der/1: deprecated (will be removed in R15A); use file:read_file/1 and public_key:pem_decode/1 ./oauth_rsa_sha1.erl:10: Warning: public_key:decode_private_key/1 is deprecated and will be removed in R15A; use public_key:pem_entry_decode/1 ./oauth_rsa_sha1.erl:22: Warning: public_key:pem_to_der/1: deprecated (will be removed in R15A); use file:read_file/1 and public_key:pem_decode/1 /opt/r14b03/bin/erlc +debug_info oauth_unix.erl The ones regarding public_key concern me, as it will break the OAuth authentication handler. I see 2 solutions: 1) upgrade erlang-oauth to the same version we have in trunk/1.2.x (doesn't produce these warnings) 2) modify the erlang-oauth in 1.1.x and use try catches where the catch would call the equivalent versions in R14/R15 (these new functions don't exist in R13B03 for example) Naturally, I would prefer 1) The warnings about http:request can be ignored I think, as in Couch we don't use any codepath that will execute the deprecated function B. On 6 October 2011 12:05, Robert Newson rnew...@apache.org wrote: Thanks all, I've pushed the change to 1.1.x. make check and futon all pass; review would still be nice. :) I simply reverted the two commits. B. On 6 October 2011 12:02, Jan Lehnardt j...@apache.org wrote: On Oct 6, 2011, at 10:30 , Robert Newson wrote: There is no build of 1.1.1 on Ubuntu 11.x that will work as well as 1.1.0, so I think it's correct that it cannot build under those conditions. Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and then focus on getting 1.2 out with 1.8.5 support (and BREAKING CHANGES). I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x. +1 Cheers Jan -- B. On 6 October 2011 09:25, Paul Davis paul.joseph.da...@gmail.com wrote: On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson rnew...@apache.org wrote: All, Paul Davis has researched the issue and it seems intractable. I would like to remove 1.8.5 support from 1.1.1. It was not present in 1.1.0 so will not be (officially) missed. The place for a breaking change of this magnitude is 1.2, not a minor bug fix release. Thoughts? B. +1 on removing the paren hack for sure. Not sure about removing 1.8.5 support completely. On the one hand, it would prevent breakage because people couldn't link against the breaking SM. On the other hand, it prevents people from linking against 1.8.5 which means it won't build on Ubuntu 11.x. Unless someone comes up with a magic option I'd say put it to an informal vote so that I can blame someone else. On 5 October 2011 18:25, Paul Davis paul.joseph.da...@gmail.com wrote: Yes, its release blocking. On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson rnew...@apache.org wrote: All, I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to include everything that was missing (Sidenote: Can we all keep this file up to date when commit bugfixes or add features?). I'd appreciate everyone giving it a look over before I start to build the release artifact. I believe there's an outstanding issue (not present in JIRA) around javascript function evaluation? Can someone confirm that it's release blocking? Thanks, B. -- Filipe David Manana, Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 6:59 PM, Robert Newson rnew...@apache.org wrote: does the newer erlang-oauth break anything? Not that I know of. On 6 October 2011 18:52, Filipe David Manana fdman...@apache.org wrote: On Thu, Oct 6, 2011 at 6:23 PM, Robert Newson rnew...@apache.org wrote: If there are no objections, I'm going to build the first 1.1.1 candidate in the morning and start a new thread for the release. As pointed out in 2 other related threads, we have some compilation warnings about functions that will no longer exist in OTP R15 (to be released by the end of this year): /opt/r14b03/bin/erlc +debug_info oauth_http.erl ./oauth_http.erl:13: Warning: http:request/4 is deprecated and will be removed in R15B; use httpc:request/4 /opt/r14b03/bin/erlc +debug_info oauth_plaintext.erl /opt/r14b03/bin/erlc +debug_info oauth_rsa_sha1.erl ./oauth_rsa_sha1.erl:9: Warning: public_key:pem_to_der/1: deprecated (will be removed in R15A); use file:read_file/1 and public_key:pem_decode/1 ./oauth_rsa_sha1.erl:10: Warning: public_key:decode_private_key/1 is deprecated and will be removed in R15A; use public_key:pem_entry_decode/1 ./oauth_rsa_sha1.erl:22: Warning: public_key:pem_to_der/1: deprecated (will be removed in R15A); use file:read_file/1 and public_key:pem_decode/1 /opt/r14b03/bin/erlc +debug_info oauth_unix.erl The ones regarding public_key concern me, as it will break the OAuth authentication handler. I see 2 solutions: 1) upgrade erlang-oauth to the same version we have in trunk/1.2.x (doesn't produce these warnings) 2) modify the erlang-oauth in 1.1.x and use try catches where the catch would call the equivalent versions in R14/R15 (these new functions don't exist in R13B03 for example) Naturally, I would prefer 1) The warnings about http:request can be ignored I think, as in Couch we don't use any codepath that will execute the deprecated function B. On 6 October 2011 12:05, Robert Newson rnew...@apache.org wrote: Thanks all, I've pushed the change to 1.1.x. make check and futon all pass; review would still be nice. :) I simply reverted the two commits. B. On 6 October 2011 12:02, Jan Lehnardt j...@apache.org wrote: On Oct 6, 2011, at 10:30 , Robert Newson wrote: There is no build of 1.1.1 on Ubuntu 11.x that will work as well as 1.1.0, so I think it's correct that it cannot build under those conditions. Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and then focus on getting 1.2 out with 1.8.5 support (and BREAKING CHANGES). I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x. +1 Cheers Jan -- B. On 6 October 2011 09:25, Paul Davis paul.joseph.da...@gmail.com wrote: On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson rnew...@apache.org wrote: All, Paul Davis has researched the issue and it seems intractable. I would like to remove 1.8.5 support from 1.1.1. It was not present in 1.1.0 so will not be (officially) missed. The place for a breaking change of this magnitude is 1.2, not a minor bug fix release. Thoughts? B. +1 on removing the paren hack for sure. Not sure about removing 1.8.5 support completely. On the one hand, it would prevent breakage because people couldn't link against the breaking SM. On the other hand, it prevents people from linking against 1.8.5 which means it won't build on Ubuntu 11.x. Unless someone comes up with a magic option I'd say put it to an informal vote so that I can blame someone else. On 5 October 2011 18:25, Paul Davis paul.joseph.da...@gmail.com wrote: Yes, its release blocking. On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson rnew...@apache.org wrote: All, I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to include everything that was missing (Sidenote: Can we all keep this file up to date when commit bugfixes or add features?). I'd appreciate everyone giving it a look over before I start to build the release artifact. I believe there's an outstanding issue (not present in JIRA) around javascript function evaluation? Can someone confirm that it's release blocking? Thanks, B. -- Filipe David Manana, Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men. -- Filipe David Manana, Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 6:05 AM, Robert Newson rnew...@apache.org wrote: Thanks all, I've pushed the change to 1.1.x. make check and futon all pass; review would still be nice. :) I simply reverted the two commits. B. That was awfully quick. :/ I would prefer to make this a social contract by doing something along the lines of requiring people to run ./configure --yes-really-give-me-1.8.5 Removing support completely seems awfully counter productive.
Re: CouchDB 1.1.1
On 6 Oct 2011, at 19:31, Paul Davis wrote: That was awfully quick. :/ Agreed. I would prefer to make this a social contract by doing something along the lines of requiring people to run ./configure --yes-really-give-me-1.8.5 -1
Re: CouchDB 1.1.1
This change came *after* discussion and +1's from multiple developers. We can certainly change direction on this but it's not like I've jumped the gun. We talked it out. B. On 6 October 2011 19:31, Paul Davis paul.joseph.da...@gmail.com wrote: On Thu, Oct 6, 2011 at 6:05 AM, Robert Newson rnew...@apache.org wrote: Thanks all, I've pushed the change to 1.1.x. make check and futon all pass; review would still be nice. :) I simply reverted the two commits. B. That was awfully quick. :/ I would prefer to make this a social contract by doing something along the lines of requiring people to run ./configure --yes-really-give-me-1.8.5 Removing support completely seems awfully counter productive.
Re: CouchDB 1.1.1
On 6 Oct 2011, at 19:35, Robert Newson wrote: This change came *after* discussion and +1's from multiple developers. We can certainly change direction on this but it's not like I've jumped the gun. We talked it out. I think a single day might be too short a time span for something like this. People may be away from their email for days at a time. Don't want to make people feel like they have to check the list every single day in case important decisions are made with out them.
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 11:31, Paul Davis paul.joseph.da...@gmail.comwrote: On Thu, Oct 6, 2011 at 6:05 AM, Robert Newson rnew...@apache.org wrote: Thanks all, I've pushed the change to 1.1.x. make check and futon all pass; review would still be nice. :) I simply reverted the two commits. B. That was awfully quick. :/ I would prefer to make this a social contract by doing something along the lines of requiring people to run ./configure --yes-really-give-me-1.8.5 Removing support completely seems awfully counter productive. Especially given that it works fine for me on Ubuntu 11.04 and with the 1.8.5 tarball download without the paren thing. The only place I've seen the paren hack be necessary is when I tried with the js bundled in Debian unstable's iceweasel, which purports to be some form of version 185 according to jsversion.h. If there's no _official_ release of a separate tarball of SpiderMonkey 1.8.5 which doesn't work with Paul's paren commit reverted then I say we keep it in 1.1.1. If distributions are still packaging the spidermonkey from inside an iceweasel/xulrunner build for 1.8.5 it's on them. Mozilla released that thing officially and it works here. -R
Re: CouchDB 1.1.1
1.1.1 contains many important fixes, holding it up to get 1.8.5 support in seems odd to me. The breakage also seems dramatic for a bug fix release and there was wide agreement on that point. Putting all of that aside, what should we do? Make it configurable at build time? Introduce all this breakage in 1.1.1 and slap a big warning on it? I'm still voting for the current state of 1.1.x, which doesn't include 1.8.5 support or the paren change. B. On 6 October 2011 19:34, Noah Slater nsla...@apache.org wrote: On 6 Oct 2011, at 19:31, Paul Davis wrote: That was awfully quick. :/ Agreed. I would prefer to make this a social contract by doing something along the lines of requiring people to run ./configure --yes-really-give-me-1.8.5 -1
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 11:37, Robert Newson rnew...@apache.org wrote: 1.1.1 contains many important fixes, holding it up to get 1.8.5 support in seems odd to me. The breakage also seems dramatic for a bug fix release and there was wide agreement on that point. Putting all of that aside, what should we do? Make it configurable at build time? Introduce all this breakage in 1.1.1 and slap a big warning on it? It's already configurable at build time via --with-js-* And again, I don't think there was a problem with any official release, just some not official version some distros yanked out of a xulrunner tarball. If you must keep the support reverted, do so. I'll say I'm -0 on it. Just a bit of a bummer. I'm still voting for the current state of 1.1.x, which doesn't include 1.8.5 support or the paren change. B. On 6 October 2011 19:34, Noah Slater nsla...@apache.org wrote: On 6 Oct 2011, at 19:31, Paul Davis wrote: That was awfully quick. :/ Agreed. I would prefer to make this a social contract by doing something along the lines of requiring people to run ./configure --yes-really-give-me-1.8.5 -1
Re: CouchDB 1.1.1
Oh, and did anyone mention that the workaround is to make your JS functions actually contain code? I think it's worth pointing out that this might not really be a serious problem, per se. On Thu, Oct 6, 2011 at 11:41, Randall Leeds randall.le...@gmail.com wrote: On Thu, Oct 6, 2011 at 11:37, Robert Newson rnew...@apache.org wrote: 1.1.1 contains many important fixes, holding it up to get 1.8.5 support in seems odd to me. The breakage also seems dramatic for a bug fix release and there was wide agreement on that point. Putting all of that aside, what should we do? Make it configurable at build time? Introduce all this breakage in 1.1.1 and slap a big warning on it? It's already configurable at build time via --with-js-* And again, I don't think there was a problem with any official release, just some not official version some distros yanked out of a xulrunner tarball. If you must keep the support reverted, do so. I'll say I'm -0 on it. Just a bit of a bummer. I'm still voting for the current state of 1.1.x, which doesn't include 1.8.5 support or the paren change. B. On 6 October 2011 19:34, Noah Slater nsla...@apache.org wrote: On 6 Oct 2011, at 19:31, Paul Davis wrote: That was awfully quick. :/ Agreed. I would prefer to make this a social contract by doing something along the lines of requiring people to run ./configure --yes-really-give-me-1.8.5 -1
Getting to start!
Dear all, I am new to CouchDB. Already, I know Erlang programming language, and now, I want to connect to couchDB in Erlang programming language. Currently, I am using windows! and Erlang/OTP (R14B04) I appreciate, if you leave me any sources or documents to start. I was confused, I should Install CouchDB as an Erlang Library? And also to connect Erlang processes to couchDB to read and write on the local computer, I should install any additional software? Best regards, /Amir * *
Re: Getting to start!
Thanks for you email Amir. You'll have better results on the general user list for now: http://couchdb.apache.org/community/lists.html Thanks! N On 6 Oct 2011, at 20:10, Amir Almasi wrote: Dear all, I am new to CouchDB. Already, I know Erlang programming language, and now, I want to connect to couchDB in Erlang programming language. Currently, I am using windows! and Erlang/OTP (R14B04) I appreciate, if you leave me any sources or documents to start. I was confused, I should Install CouchDB as an Erlang Library? And also to connect Erlang processes to couchDB to read and write on the local computer, I should install any additional software? Best regards, /Amir * *
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122206#comment-13122206
]
Paul Joseph Davis commented on COUCHDB-1302:
Ok. Here's the situation:
First, an anonymous function at the root of a scope is invalid JavaScript. Ie,
the following is invalid:
function(doc) {emit(doc._id, 1);}
Is broken JavaScript.
But, SpiderMonkey has had an option for years [1] that allowed this.
SpiderMonkey happened to be the only interpreter that has had this. The setting
JSOPTION_ANONFUNFIX existed to enforce the error mechanism. The thing is, it
was off by default (ie, the error was not triggered by default) in older js
shells.
Recently, this appears to have caused an error for SpiderMonkey passing the
JavaScript test suite [2]. Along with this patch, the js shell from SM 1.8.5
enables JSOPTION_ANONFUNFIX so all of the js shell tests we were doing were
misleading. couchjs works with the 1.8.5 tarball from Mozilla. It does not work
starting when [2] was applied to trunk (after the 1.8.5 tarball was created).
So bottom line, this isn't an issue for all of the tarballs from Mozilla's
official FTP site, but it will be an issue moving forward.
So the plan I'm proposing is this:
1. Re-enable support for 1.8.5 on 1.1.x for 1.1.1
2. Revert the paren hack across the board.
3. Add a configure check for JSOPTION_ANONFUNFIX so we can detect if
user code will break (and perhaps add an option to override it)
4. Update 1.2.x with some new behavior that will force people to upgrade
all of their function definitions to be correct moving forward. Also note
that
this would be backwards compatible if the named function is the last
statement
as we currently require which should be enforceable in the future (if we so
desire).
I think 1, 2, and 3 are relatively uncontroversial at this point. We now know
how to detect exactly when old code will break and can warn about it (ie, by
refusing to build, (the option to override I'm less certain about, I'd be +0.5
at this point)).
As to 4, the behavior I would propose at this point is that all of our JS
definitions would require a name in the future. For instance:
function(doc) {emit(doc._id, 1);}
becomes:
function map(doc) {emit(doc._id, 1);}
And then couchjs+main.js gets modified to look for these specific names. I'm
thinking we'd end up with map, reduce, filter, validate, show,
list, and update given our current set of user definable functions. For
users we'd also need to make our error messages better. Currently, the error
without these names would be something generic like expression does not
evaluate to a function or similar which could be change to something like No
function named 'map' or similar (though, that obviously needs work cause it
could be a real syntax error as well).
So, 1, 2, and 3 have my +1. I think 4 is probably best going forward, but we
can open a new ticket about how to deal with the it for 1.2.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=377433
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=665835
Fix couchjs
---
Key: COUCHDB-1302
URL: https://issues.apache.org/jira/browse/COUCHDB-1302
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Affects Versions: 1.1.1, 1.2, 1.3
Reporter: Paul Joseph Davis
Priority: Blocker
Figure out why some spidermonkeys have an error when doing:
eval(function(){})
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122217#comment-13122217
]
Adam Kocoloski commented on COUCHDB-1302:
-
+1 from me on points 1,2,3. Thanks for tracking this down Paul.
Fix couchjs
---
Key: COUCHDB-1302
URL: https://issues.apache.org/jira/browse/COUCHDB-1302
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Affects Versions: 1.1.1, 1.2, 1.3
Reporter: Paul Joseph Davis
Priority: Blocker
Figure out why some spidermonkeys have an error when doing:
eval(function(){})
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122252#comment-13122252
]
Noah Slater commented on COUCHDB-1302:
--
I am +0 on having an over-ride ./configure flag.
The rest seem perfectly reasonable, so +1 on those.
Even 4 sounds okay, TBH. Though I'd be open to seeing other suggestions too!
Fix couchjs
---
Key: COUCHDB-1302
URL: https://issues.apache.org/jira/browse/COUCHDB-1302
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Affects Versions: 1.1.1, 1.2, 1.3
Reporter: Paul Joseph Davis
Priority: Blocker
Figure out why some spidermonkeys have an error when doing:
eval(function(){})
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122274#comment-13122274
]
Benoit Chesneau commented on COUCHDB-1302:
--
+1 on 1,2,3 . thanks :)
Fix couchjs
---
Key: COUCHDB-1302
URL: https://issues.apache.org/jira/browse/COUCHDB-1302
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Affects Versions: 1.1.1, 1.2, 1.3
Reporter: Paul Joseph Davis
Priority: Blocker
Figure out why some spidermonkeys have an error when doing:
eval(function(){})
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-642) Support rev in PUT URL
[
https://issues.apache.org/jira/browse/COUCHDB-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122275#comment-13122275
]
Benjamin Young commented on COUCHDB-642:
From a REST perspective nothing in the query string or header should take
precedence over the content body. Meaning, the rev query parameter value
really shouldn't override the _rev keys value in the document. Updating the
_rev in the JSON object seems like a very small cost in exchange for the
cumbersome order of preference given to various query parameters or headers.
The content body is the canonical source for the document--especially in
regards to a PUT.
The DELETE case doesn't require a content body, so issuing it with a rev is
mandatory as it semantically specifies the resource your deleting. You can
delete documents via POST, but in that case the _rev is included in the content
body (as it should be)--which matches the PUT use case.
-1 as it's just not worth the confusion cost for a nice-to-have.
Support rev in PUT URL
--
Key: COUCHDB-642
URL: https://issues.apache.org/jira/browse/COUCHDB-642
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Environment: trunk 08 Feb 2010
Reporter: Brian Candler
Priority: Minor
Attachments: 0001-Allow-for-the-current-revision-number-to-be.patch
A DELETE request lets you append ?rev= to the URL. But this doesn't work
with a PUT request; you have to put the _rev in the body instead (even though
the _id is taken from the URL path)
$ curl -X PUT -d {}
http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo
{ok:true,id:foo,rev:1-967a00dff5e02add41819138abb3284d}
$ curl -X PUT -d {}
http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo?rev=1-967a00dff5e02add41819138abb3284d
{error:conflict,reason:Document update conflict.}
$ curl -X PUT -d '{_rev:1-967a00dff5e02add41819138abb3284d}'
http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo
{ok:true,id:foo,rev:2-7051cbe5c8faecd085a3fa619e6e6337}
Allowing ?rev in the URL would make PUT and DELETE more consistent, and would
allow you to replace an existing JSON doc with another one without having to
merge the _rev into it first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122280#comment-13122280
]
Robert Newson commented on COUCHDB-1302:
+1 on 1,2,3.
Not keen on configure option in 1.1.1 but will go with the flow (though let's
decide soon pls).
for point 4, while that signature looks much nicer, is it too much of a break
for 1.2? Feels like a 2.0 thing. If there's agreement, then the remaining
question is what branch becomes 2.0. Oh, the joy.
Fix couchjs
---
Key: COUCHDB-1302
URL: https://issues.apache.org/jira/browse/COUCHDB-1302
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Affects Versions: 1.1.1, 1.2, 1.3
Reporter: Paul Joseph Davis
Priority: Blocker
Figure out why some spidermonkeys have an error when doing:
eval(function(){})
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122427#comment-13122427
]
Randall Leeds commented on COUCHDB-1302:
+1 on 1 and 2.
+1 for 3. I'll write this up for 1.1.x if Paul doesn't beat me to it. 1.2/2.0
needs something different though.
Paul discovered and mentioned in IRC that we can't actually look for the last
function if people use named functions because eval('function map(...){...}')
=== undefined. In other words, we need to pull 'map' out of the global scope
after the call to eval() so it needs to have a well-known name.
So we're stuck opening up the 2.0 can of worms it seems. We should consider
what the cleanest looking design document that makes this all look sane is and
what effect any changes have on the way we index and optimize work for
calculating design doc indexes.
We should focus on 1.1.1 and then open the bikeshed floodgates.
Fix couchjs
---
Key: COUCHDB-1302
URL: https://issues.apache.org/jira/browse/COUCHDB-1302
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Affects Versions: 1.1.1, 1.2, 1.3
Reporter: Paul Joseph Davis
Priority: Blocker
Figure out why some spidermonkeys have an error when doing:
eval(function(){})
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-642) Support rev in PUT URL
[
https://issues.apache.org/jira/browse/COUCHDB-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122491#comment-13122491
]
Randall Leeds commented on COUCHDB-642:
---
Oh. I have this work already done. I'll double check that the preference
ordering makes sense. I don't have any philosophical objection to allowing it
in the URL and the way I've written it already asserts that if it's present in
more than one place it has to match everywhere or it's a bad request.
Support rev in PUT URL
--
Key: COUCHDB-642
URL: https://issues.apache.org/jira/browse/COUCHDB-642
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Environment: trunk 08 Feb 2010
Reporter: Brian Candler
Priority: Minor
Attachments: 0001-Allow-for-the-current-revision-number-to-be.patch
A DELETE request lets you append ?rev= to the URL. But this doesn't work
with a PUT request; you have to put the _rev in the body instead (even though
the _id is taken from the URL path)
$ curl -X PUT -d {}
http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo
{ok:true,id:foo,rev:1-967a00dff5e02add41819138abb3284d}
$ curl -X PUT -d {}
http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo?rev=1-967a00dff5e02add41819138abb3284d
{error:conflict,reason:Document update conflict.}
$ curl -X PUT -d '{_rev:1-967a00dff5e02add41819138abb3284d}'
http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo
{ok:true,id:foo,rev:2-7051cbe5c8faecd085a3fa619e6e6337}
Allowing ?rev in the URL would make PUT and DELETE more consistent, and would
allow you to replace an existing JSON doc with another one without having to
merge the _rev into it first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (COUCHDB-642) Support rev in PUT URL
[
https://issues.apache.org/jira/browse/COUCHDB-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds reassigned COUCHDB-642:
-
Assignee: Randall Leeds
Support rev in PUT URL
--
Key: COUCHDB-642
URL: https://issues.apache.org/jira/browse/COUCHDB-642
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Environment: trunk 08 Feb 2010
Reporter: Brian Candler
Assignee: Randall Leeds
Priority: Minor
Attachments: 0001-Allow-for-the-current-revision-number-to-be.patch
A DELETE request lets you append ?rev= to the URL. But this doesn't work
with a PUT request; you have to put the _rev in the body instead (even though
the _id is taken from the URL path)
$ curl -X PUT -d {}
http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo
{ok:true,id:foo,rev:1-967a00dff5e02add41819138abb3284d}
$ curl -X PUT -d {}
http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo?rev=1-967a00dff5e02add41819138abb3284d
{error:conflict,reason:Document update conflict.}
$ curl -X PUT -d '{_rev:1-967a00dff5e02add41819138abb3284d}'
http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo
{ok:true,id:foo,rev:2-7051cbe5c8faecd085a3fa619e6e6337}
Allowing ?rev in the URL would make PUT and DELETE more consistent, and would
allow you to replace an existing JSON doc with another one without having to
merge the _rev into it first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122519#comment-13122519
]
Paul Joseph Davis commented on COUCHDB-1302:
I agree with Randall. I think we have a plan for 1.1.1 that's sane. The 1.2 can
of worms is going to be a big one so we should make sure and separate the
issues there.
Fix couchjs
---
Key: COUCHDB-1302
URL: https://issues.apache.org/jira/browse/COUCHDB-1302
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Affects Versions: 1.1.1, 1.2, 1.3
Reporter: Paul Joseph Davis
Priority: Blocker
Figure out why some spidermonkeys have an error when doing:
eval(function(){})
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
