Re: Problems blocking 1.2.0 release
Doing some traveling but quick thoughts inline: On Fri, Feb 3, 2012 at 6:29 PM, Noah Slater wrote: > Hello, > > I have a 1.2.0 release ready to go, but there are a few problems that need > fixing before I am prepared to ship. > > Comparing our source to the release artefact, I get: > > Only in 1.2.0/src/mochiweb: mochiweb.app.src IIRC, I think I noticed that we're not generating a mochiweb.app from this file. It needs to be there and we need to generate it and there's a pattern. Just needs a rule in the make file and an EXTRA_DIST entry for the .app I think. >> Only in 1.2.0/src/mochiweb: mochiweb_request_tests.erl This can probably be deleted outright assuming make check doesn't try and use it (and I don't think it does). >> Only in apache-couchdb-1.2.0/src/snappy: Makefile.in No idea what this business is. An artefact of the snappy build? Just delete it? >> Only in 1.2.0/src/snappy/google-snappy: AUTHORS EXTRA_DIST? Delete? >> Only in 1.2.0/src/snappy/google-snappy: COPYING We should look on whether we keep this or not. There's probably ASF guidelines on what to do here. I'm guessing either delete it or add it to NOTICE in the root. >> Only in apache-couchdb-1.2.0/src/snappy/google-snappy: >> snappy-stubs-public.h > Not sure why this is made by bootstrap. Might be a valid reason, might just need the generation to happen during make instead. > > For lines that start: > > Only in 1.2.0 > > > The only time this should ever happen is when the file is used by the > bootstrap process, or Git, and can be discarded after bootstrapping. > Clearly, none of these files pass that requirement. Which means that we > should be shipping them in the source tarball. Probably by adding them to > EXTRA_DIST or something. > > For lines that start: > > Only in apache-couchdb-1.2.0 > > > The only time this should ever happen is when the file is created by the > bootstrap process, or need to be made on the assumption that our users will > not be able to make them, as is the case for our man pages. Clearly, none > of these files pass that requirement. Now, I checked the snappy makefile, > and it looks like we're shipping these generated files on purpose, which is > very strange. > > So, over to you, Paul, I guess. Want to weigh in on these? They need fixing > on master as well as the release branch. > > Thanks, > > N
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200245#comment-13200245
]
Jason Smith commented on COUCHDB-1397:
--
@Paul, good points.
So, we disagree on where to make the trade-off. That's fine. I yield to you and
the community if that is its consensus. (Is it?)
CouchDB should support the ubiquitous, nice-looking, and relaxing "invalid"
style even if that means "(" + ")". But it should *not* support helper function
people. Obviously that is just IMO.
But if CouchDB *does* change and we *do* start writing valid
statements/programs in our ddocs, Max's suggestion of the
standard--CommonJS--is clearly best.
> Function expressions, evals in SpiderMonkey
> ---
>
> Key: COUCHDB-1397
> URL: https://issues.apache.org/jira/browse/COUCHDB-1397
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 1.2.1
> Environment: All
>Reporter: Jason Smith
>
> New SpiderMonkey releases do not eval() a sole anonymous function expression.
> That is not a valid JavaScript statement, and so it is not a valid JavaScript
> script.
> COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
> 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.")
--
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: How to connect couchdb through javascript
> On Friday, 3 February 2012 at 03:53, arunav wrote: > >> I am new to couchDB. I need a simple java script code for connecting CouchDB >> database and reading a document and displaying the content in the browser >> window. I found the best place to start was to read the Definitive Guide, and translate each curl…. into AJAX. Piece of cake. Let us know how you get on & maybe we can give you something more specific. A+ Dave
Problems blocking 1.2.0 release
Hello, I have a 1.2.0 release ready to go, but there are a few problems that need fixing before I am prepared to ship. Comparing our source to the release artefact, I get: Only in 1.2.0/src/mochiweb: mochiweb.app.src > Only in 1.2.0/src/mochiweb: mochiweb_request_tests.erl > Only in apache-couchdb-1.2.0/src/snappy: Makefile.in > Only in 1.2.0/src/snappy/google-snappy: AUTHORS > Only in 1.2.0/src/snappy/google-snappy: COPYING > Only in apache-couchdb-1.2.0/src/snappy/google-snappy: > snappy-stubs-public.h For lines that start: Only in 1.2.0 The only time this should ever happen is when the file is used by the bootstrap process, or Git, and can be discarded after bootstrapping. Clearly, none of these files pass that requirement. Which means that we should be shipping them in the source tarball. Probably by adding them to EXTRA_DIST or something. For lines that start: Only in apache-couchdb-1.2.0 The only time this should ever happen is when the file is created by the bootstrap process, or need to be made on the assumption that our users will not be able to make them, as is the case for our man pages. Clearly, none of these files pass that requirement. Now, I checked the snappy makefile, and it looks like we're shipping these generated files on purpose, which is very strange. So, over to you, Paul, I guess. Want to weigh in on these? They need fixing on master as well as the release branch. Thanks, N
[jira] [Commented] (COUCHDB-1400) Critical crash of Futon after misconfigured bind_address
[ https://issues.apache.org/jira/browse/COUCHDB-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200082#comment-13200082 ] Robert Newson commented on COUCHDB-1400: the bind_address is only stored in the .ini files, it doesn't come from anywhere else. Therefore I think it's more likely that you haven't reset your .ini files correctly. If couchdb is currently running, you can use netstat to see if it's bound to any interface. You can also tweak bind_address over http, assuming couch is bound to at least one interface. If it's bound to zero interfaces, then there's not much we can do about it. Again, we can more easily assist with this support question on a support channel rather than our bug tracker. > Critical crash of Futon after misconfigured bind_address > > > Key: COUCHDB-1400 > URL: https://issues.apache.org/jira/browse/COUCHDB-1400 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 0.11.2 > Environment: CentOS 5.5 (64-bit) >Reporter: Tim > Labels: Futon,, crash > Attachments: screenshot-1.jpg > > > Bug1: Unable to reflect bind_address in local.ini > Bug2: Unable to revert changes doing clean install > Bug3: Can only change bind_address in Futon > I made a mistake to change the configuration table's httpd/bind_address > parameter to my domain, the domain that looks like www.google.com etc. That > was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this > mistake long time ago but now basically I can't access anything from either > localhost and external. > Please check screenshot to see what it looks like when I try to access Futon > after misconfiguration. > I am unable to reverse my setting because working with > /etc/couchdb/default.ini or local.ini never affected this in the first place > (spent 2 hours trying to modify these fails in order to get external access > of couchDB). > So Futon must have changed something when I set it. When I change the value, > it stuck at the error: Some of the changes require database restart. Since > then, I can never access my couchDB. > I tried to yum remove erlang, yum remove couchdb several times. Checked to > see if any default.ini or local.ini remains, restart system, log out users, > but none of above works. > Please help me with this problem as soon as possible. -- 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] [Updated] (COUCHDB-1400) Critical crash of Futon after misconfigured bind_address
[ https://issues.apache.org/jira/browse/COUCHDB-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim updated COUCHDB-1400: - Description: Bug1: Unable to reflect bind_address in local.ini Bug2: Unable to revert changes doing clean install Bug3: Can only change bind_address in Futon I made a mistake to change the configuration table's httpd/bind_address parameter to my domain, the domain that looks like www.google.com etc. That was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this mistake long time ago but now basically I can't access anything from either localhost and external. Please check screenshot to see what it looks like when I try to access Futon after misconfiguration. I am unable to reverse my setting because working with /etc/couchdb/default.ini or local.ini never affected this in the first place (spent 2 hours trying to modify these fails in order to get external access of couchDB). So Futon must have changed something when I set it. When I change the value, it stuck at the error: Some of the changes require database restart. Since then, I can never access my couchDB. I tried to yum remove erlang, yum remove couchdb several times. Checked to see if any default.ini or local.ini remains, restart system, log out users, but none of above works. Please help me with this problem as soon as possible. was: I made a mistake to change the configuration table's httpd/bind_address parameter to my domain, the domain that looks like www.google.com etc. That was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this mistake long time ago but now basically I can't access anything from either localhost and external. Please check screenshot to see what it looks like when I try to access Futon after misconfiguration. I am unable to reverse my setting because working with /etc/couchdb/default.ini or local.ini never affected this in the first place (spent 2 hours trying to modify these fails in order to get external access of couchDB). So Futon must have changed something when I set it. When I change the value, it stuck at the error: Some of the changes require database restart. Since then, I can never access my couchDB. I tried to yum remove erlang, yum remove couchdb several times. Checked to see if any default.ini or local.ini remains, restart system, log out users, but none of above works. Please help me with this problem as soon as possible. > Critical crash of Futon after misconfigured bind_address > > > Key: COUCHDB-1400 > URL: https://issues.apache.org/jira/browse/COUCHDB-1400 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 0.11.2 > Environment: CentOS 5.5 (64-bit) >Reporter: Tim > Labels: Futon,, crash > Attachments: screenshot-1.jpg > > > Bug1: Unable to reflect bind_address in local.ini > Bug2: Unable to revert changes doing clean install > Bug3: Can only change bind_address in Futon > I made a mistake to change the configuration table's httpd/bind_address > parameter to my domain, the domain that looks like www.google.com etc. That > was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this > mistake long time ago but now basically I can't access anything from either > localhost and external. > Please check screenshot to see what it looks like when I try to access Futon > after misconfiguration. > I am unable to reverse my setting because working with > /etc/couchdb/default.ini or local.ini never affected this in the first place > (spent 2 hours trying to modify these fails in order to get external access > of couchDB). > So Futon must have changed something when I set it. When I change the value, > it stuck at the error: Some of the changes require database restart. Since > then, I can never access my couchDB. > I tried to yum remove erlang, yum remove couchdb several times. Checked to > see if any default.ini or local.ini remains, restart system, log out users, > but none of above works. > Please help me with this problem as soon as possible. -- 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-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200071#comment-13200071 ] Paul Joseph Davis commented on COUCHDB-1397: @Benoit That's what I was trying to describe earlier. The draw backs that come to mind is that it's quite a break with the current behavior (and harder to detect the difference) and we'd probably want to add some sort of "context" member that is compiled and executed once when the map or reduce is run (only once for maps, and once per reduce call). Or we can just force people to abuse the commonjs cache maybe? > Function expressions, evals in SpiderMonkey > --- > > Key: COUCHDB-1397 > URL: https://issues.apache.org/jira/browse/COUCHDB-1397 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Affects Versions: 1.2.1 > Environment: All >Reporter: Jason Smith > > New SpiderMonkey releases do not eval() a sole anonymous function expression. > That is not a valid JavaScript statement, and so it is not a valid JavaScript > script. > COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for > 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.") -- 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: How to connect couchdb through javascript
Hi, Futon does this, so dig into that. There are other alternatives (Backbone for instance) but they are maybe over kill for a simple page, you don't really go into details about what you want to achieve. Cheers Simon On Friday, 3 February 2012 at 03:53, arunav wrote: > I am new to couchDB. I need a simple java script code for connecting CouchDB > database and reading a document and displaying the content in the browser > window. > > Please anyone help me. > > > Thanks, > Aruna > > -- > View this message in context: > http://couchdb-development.1959287.n2.nabble.com/How-to-connect-couchdb-through-javascript-tp7249589p7249589.html > Sent from the CouchDB Development mailing list archive at Nabble.com > (http://Nabble.com). > >
[jira] [Commented] (COUCHDB-1400) Critical crash of Futon after misconfigured bind_address
[ https://issues.apache.org/jira/browse/COUCHDB-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200055#comment-13200055 ] Tim commented on COUCHDB-1400: -- Tried all those. Is it not a bug if I change local.ini and restart but nothing changed? Also the ini had proper bind_address when i reinstalled it. > Critical crash of Futon after misconfigured bind_address > > > Key: COUCHDB-1400 > URL: https://issues.apache.org/jira/browse/COUCHDB-1400 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 0.11.2 > Environment: CentOS 5.5 (64-bit) >Reporter: Tim > Labels: Futon,, crash > Attachments: screenshot-1.jpg > > > I made a mistake to change the configuration table's httpd/bind_address > parameter to my domain, the domain that looks like www.google.com etc. That > was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this > mistake long time ago but now basically I can't access anything from either > localhost and external. > Please check screenshot to see what it looks like when I try to access Futon > after misconfiguration. > I am unable to reverse my setting because working with > /etc/couchdb/default.ini or local.ini never affected this in the first place > (spent 2 hours trying to modify these fails in order to get external access > of couchDB). > So Futon must have changed something when I set it. When I change the value, > it stuck at the error: Some of the changes require database restart. Since > then, I can never access my couchDB. > I tried to yum remove erlang, yum remove couchdb several times. Checked to > see if any default.ini or local.ini remains, restart system, log out users, > but none of above works. > Please help me with this problem as soon as possible. -- 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] [Resolved] (COUCHDB-1400) Critical crash of Futon after misconfigured bind_address
[ https://issues.apache.org/jira/browse/COUCHDB-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson resolved COUCHDB-1400. Resolution: Not A Problem Fix Version/s: (was: 0.11.2) Not a bug, just a misconfigured server. > Critical crash of Futon after misconfigured bind_address > > > Key: COUCHDB-1400 > URL: https://issues.apache.org/jira/browse/COUCHDB-1400 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 0.11.2 > Environment: CentOS 5.5 (64-bit) >Reporter: Tim > Labels: Futon,, crash > Attachments: screenshot-1.jpg > > > I made a mistake to change the configuration table's httpd/bind_address > parameter to my domain, the domain that looks like www.google.com etc. That > was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this > mistake long time ago but now basically I can't access anything from either > localhost and external. > Please check screenshot to see what it looks like when I try to access Futon > after misconfiguration. > I am unable to reverse my setting because working with > /etc/couchdb/default.ini or local.ini never affected this in the first place > (spent 2 hours trying to modify these fails in order to get external access > of couchDB). > So Futon must have changed something when I set it. When I change the value, > it stuck at the error: Some of the changes require database restart. Since > then, I can never access my couchDB. > I tried to yum remove erlang, yum remove couchdb several times. Checked to > see if any default.ini or local.ini remains, restart system, log out users, > but none of above works. > Please help me with this problem as soon as possible. -- 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-1400) Critical crash of Futon after misconfigured bind_address
[ https://issues.apache.org/jira/browse/COUCHDB-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200047#comment-13200047 ] Robert Newson commented on COUCHDB-1400: Hi, You should stop couchdb (and verify that the process is not running), then fix local.ini (restore 0.0.0.0 for bind_address) and then start it up again. I suggest hopping on our IRC channel #couchdb on irc.freenode.net or the user@ mailing list. JIRA is for bug reports, not support. B. > Critical crash of Futon after misconfigured bind_address > > > Key: COUCHDB-1400 > URL: https://issues.apache.org/jira/browse/COUCHDB-1400 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 0.11.2 > Environment: CentOS 5.5 (64-bit) >Reporter: Tim > Labels: Futon,, crash > Attachments: screenshot-1.jpg > > > I made a mistake to change the configuration table's httpd/bind_address > parameter to my domain, the domain that looks like www.google.com etc. That > was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this > mistake long time ago but now basically I can't access anything from either > localhost and external. > Please check screenshot to see what it looks like when I try to access Futon > after misconfiguration. > I am unable to reverse my setting because working with > /etc/couchdb/default.ini or local.ini never affected this in the first place > (spent 2 hours trying to modify these fails in order to get external access > of couchDB). > So Futon must have changed something when I set it. When I change the value, > it stuck at the error: Some of the changes require database restart. Since > then, I can never access my couchDB. > I tried to yum remove erlang, yum remove couchdb several times. Checked to > see if any default.ini or local.ini remains, restart system, log out users, > but none of above works. > Please help me with this problem as soon as possible. -- 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] [Updated] (COUCHDB-1400) Critical crash of Futon after misconfigured bind_address
[ https://issues.apache.org/jira/browse/COUCHDB-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim updated COUCHDB-1400: - Attachment: screenshot-1.jpg This is what _utils(Futon) looks like after the misconfiguration. > Critical crash of Futon after misconfigured bind_address > > > Key: COUCHDB-1400 > URL: https://issues.apache.org/jira/browse/COUCHDB-1400 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 0.11.2 > Environment: CentOS 5.5 (64-bit) >Reporter: Tim > Labels: Futon,, crash > Fix For: 0.11.2 > > Attachments: screenshot-1.jpg > > > I made a mistake to change the configuration table's httpd/bind_address > parameter to my domain, the domain that looks like www.google.com etc. That > was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this > mistake long time ago but now basically I can't access anything from either > localhost and external. > I am unable to reverse my setting because working with > /etc/couchdb/default.ini or local.ini never affected this in the first place > (spent 2 hours trying to modify these fails in order to get external access > of couchDB). > So Futon must have changed something when I set it. When I change the value, > it stuck at the error: Some of the changes require database restart. Since > then, I can never access my couchDB. > I tried to yum remove erlang, yum remove couchdb several times. Checked to > see if any default.ini or local.ini remains, restart system, log out users, > but none of above works. > Please help me with this problem as soon as possible. -- 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] [Updated] (COUCHDB-1400) Critical crash of Futon after misconfigured bind_address
[ https://issues.apache.org/jira/browse/COUCHDB-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim updated COUCHDB-1400: - Description: I made a mistake to change the configuration table's httpd/bind_address parameter to my domain, the domain that looks like www.google.com etc. That was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this mistake long time ago but now basically I can't access anything from either localhost and external. Please check screenshot to see what it looks like when I try to access Futon after misconfiguration. I am unable to reverse my setting because working with /etc/couchdb/default.ini or local.ini never affected this in the first place (spent 2 hours trying to modify these fails in order to get external access of couchDB). So Futon must have changed something when I set it. When I change the value, it stuck at the error: Some of the changes require database restart. Since then, I can never access my couchDB. I tried to yum remove erlang, yum remove couchdb several times. Checked to see if any default.ini or local.ini remains, restart system, log out users, but none of above works. Please help me with this problem as soon as possible. was: I made a mistake to change the configuration table's httpd/bind_address parameter to my domain, the domain that looks like www.google.com etc. That was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this mistake long time ago but now basically I can't access anything from either localhost and external. I am unable to reverse my setting because working with /etc/couchdb/default.ini or local.ini never affected this in the first place (spent 2 hours trying to modify these fails in order to get external access of couchDB). So Futon must have changed something when I set it. When I change the value, it stuck at the error: Some of the changes require database restart. Since then, I can never access my couchDB. I tried to yum remove erlang, yum remove couchdb several times. Checked to see if any default.ini or local.ini remains, restart system, log out users, but none of above works. Please help me with this problem as soon as possible. > Critical crash of Futon after misconfigured bind_address > > > Key: COUCHDB-1400 > URL: https://issues.apache.org/jira/browse/COUCHDB-1400 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 0.11.2 > Environment: CentOS 5.5 (64-bit) >Reporter: Tim > Labels: Futon,, crash > Fix For: 0.11.2 > > Attachments: screenshot-1.jpg > > > I made a mistake to change the configuration table's httpd/bind_address > parameter to my domain, the domain that looks like www.google.com etc. That > was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this > mistake long time ago but now basically I can't access anything from either > localhost and external. > Please check screenshot to see what it looks like when I try to access Futon > after misconfiguration. > I am unable to reverse my setting because working with > /etc/couchdb/default.ini or local.ini never affected this in the first place > (spent 2 hours trying to modify these fails in order to get external access > of couchDB). > So Futon must have changed something when I set it. When I change the value, > it stuck at the error: Some of the changes require database restart. Since > then, I can never access my couchDB. > I tried to yum remove erlang, yum remove couchdb several times. Checked to > see if any default.ini or local.ini remains, restart system, log out users, > but none of above works. > Please help me with this problem as soon as possible. -- 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] [Created] (COUCHDB-1400) Critical crash of Futon after misconfigured bind_address
Critical crash of Futon after misconfigured bind_address Key: COUCHDB-1400 URL: https://issues.apache.org/jira/browse/COUCHDB-1400 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 0.11.2 Environment: CentOS 5.5 (64-bit) Reporter: Tim Fix For: 0.11.2 I made a mistake to change the configuration table's httpd/bind_address parameter to my domain, the domain that looks like www.google.com etc. That was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this mistake long time ago but now basically I can't access anything from either localhost and external. I am unable to reverse my setting because working with /etc/couchdb/default.ini or local.ini never affected this in the first place (spent 2 hours trying to modify these fails in order to get external access of couchDB). So Futon must have changed something when I set it. When I change the value, it stuck at the error: Some of the changes require database restart. Since then, I can never access my couchDB. I tried to yum remove erlang, yum remove couchdb several times. Checked to see if any default.ini or local.ini remains, restart system, log out users, but none of above works. Please help me with this problem as soon as possible. -- 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] [Updated] (COUCHDB-1398) improve view filtering in changes
[
https://issues.apache.org/jira/browse/COUCHDB-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Chesneau updated COUCHDB-1398:
-
Attachment: 0009-handle-native-filters-in-views.patch
0008-whitespaces.patch
handle native filters in replication.
Native filters wasn't handled by the replication. Fix it. While I'm here parse
the view argument for the _view filter.
Note: this fix must be ported to 1.2 & last head.
> improve view filtering in changes
> -
>
> Key: COUCHDB-1398
> URL: https://issues.apache.org/jira/browse/COUCHDB-1398
> Project: CouchDB
> Issue Type: Improvement
> Components: View Server Support
>Affects Versions: 2.0, 1.3
>Reporter: Benoit Chesneau
> Labels: changes, view
> Attachments: 0001-white-spaces.patch,
> 0002-initial-step-move-the-code-from-couch_httpd_db-to-co.patch,
> 0003-fix-indent.patch,
> 0004-This-wrapper-is-useless-somehow-split-the-code-in-a-.patch,
> 0005-add-view_updated-event.patch, 0006-immprove-view-filter.patch,
> 0007-useless-info.patch, 0008-whitespaces.patch,
> 0009-handle-native-filters-in-views.patch
>
>
> Improve the native view filter `_view` support by really using view index.
> This patches add following features
> - small refactoring: create the couch_httpd_changes modules, to put all the
> changes http support in its own module instead having it in couch_httpd_db.
> - add the `view_updated` event when a view index is updated : {view_updated,
> {DbName, IndexName}}
> - start the feed using results in the view index instead of all the db index
> - only react on view index changes.
> For now next changes are still get using the couch_db:changes_since function
> and passing the map function to the results. It could be improved if we had a
> by_seq btree in the view index too. Other way may be to skip a number of the
> documents already processed. Not sure it would be faster. Thoughts ?
> The branch couch_view_changes in my repo contains preliminary support:
> https://github.com/benoitc/couchdb/tree/couch_view_changes
> Diff:
> https://github.com/benoitc/couchdb/compare/master...couch_view_changes
> To use it, use the native filter named _view which take the parameter
> view=DesignName/Viewname
> eg:
>
> http://server/db/_changes?feed=continuous&heartbeat=true&filter=_view&view=DesignName/SomeView
> It has also an interresting side effect: on each db updates the view index
> refresh is triggered so view updates are triggered. Maybe we could introduce
> an optionnal parameter to not trigger them though?
--
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-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199904#comment-13199904
]
Benoit Chesneau commented on COUCHDB-1397:
--
Having a json which would do { "views": "name": { "map": "function map(doc)
{}"}} is somehow inelegant and redundant imo.
The other solution { "views": "name": "function map(doc) {} .. function
reduce(doc) {}" } may be confusing:
- I can introduce the idea that people could share vars between this functions,
while they are used at different states. For example what would happen if
smeone shatre the results of the map function to the reduce function.
- Since these functions are used at different steps, why sharing them in the
same member ?
I think it may be better to keep the current split in different properties of
the design doc. I like the idea of elasticsearch to just pass script with a
global context inside.
we could have something like:
map = "some script" which could base a Ctx object containing all the neded
info:
ctx.doc
ctx.ddoc ...
then tue script could just return or emit.
What do you think?
> Function expressions, evals in SpiderMonkey
> ---
>
> Key: COUCHDB-1397
> URL: https://issues.apache.org/jira/browse/COUCHDB-1397
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 1.2.1
> Environment: All
>Reporter: Jason Smith
>
> New SpiderMonkey releases do not eval() a sole anonymous function expression.
> That is not a valid JavaScript statement, and so it is not a valid JavaScript
> script.
> COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
> 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.")
--
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-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199892#comment-13199892
]
James Howe commented on COUCHDB-1397:
-
The string "function(doc) {}" *isnt* invalid JavaScript - it's just a string.
It only becomes an anonymous function at global scope if you pass it directly
to eval().
> Function expressions, evals in SpiderMonkey
> ---
>
> Key: COUCHDB-1397
> URL: https://issues.apache.org/jira/browse/COUCHDB-1397
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 1.2.1
> Environment: All
>Reporter: Jason Smith
>
> New SpiderMonkey releases do not eval() a sole anonymous function expression.
> That is not a valid JavaScript statement, and so it is not a valid JavaScript
> script.
> COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
> 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.")
--
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-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199838#comment-13199838 ] Paul Joseph Davis commented on COUCHDB-1397: Firstly, I'm not thinking of eval, I'm thinking of JS_CompileScript/JS_CompileUCScript which is where this restriction is actually applied. Secondly, I didn't say transforms are out of the question, I said they are heavily discouraged. The reason for discouraging them is because they break shit as demonstrated by all the people that wrote in to tell me I broke shit with the simple paren wrapping approach not to mention that this is the sort of engineering that leads to SQL injection. Just because it's the easy answer for some folks doesn't necessarily mean its the right call. > Function expressions, evals in SpiderMonkey > --- > > Key: COUCHDB-1397 > URL: https://issues.apache.org/jira/browse/COUCHDB-1397 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Affects Versions: 1.2.1 > Environment: All >Reporter: Jason Smith > > New SpiderMonkey releases do not eval() a sole anonymous function expression. > That is not a valid JavaScript statement, and so it is not a valid JavaScript > script. > COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for > 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.") -- 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: Auth failure and 401 not working on windows in 1.1.1
Got it. Just in case someone needs this thread in the future the issue was me. I reset the DB but did not rteset the security roles on the DB. -- View this message in context: http://couchdb-development.1959287.n2.nabble.com/Auth-failure-and-401-not-working-on-windows-in-1-1-1-tp7245802p7251203.html Sent from the CouchDB Development mailing list archive at Nabble.com.
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199794#comment-13199794 ] Jason Smith commented on COUCHDB-1397: -- And since when has the contents of "map" become a global scope? Who made that decision? Was it you? Really, if eval() is the only arrow in your quiver then it's no wonder you see the problem this way. And how have you decided so-called "source-to-source translations" are out of the question? They are the backbone of JavasScript encapsulation, undergirding CommonJS (CouchDB and Node), RequireJS, Ender.js, and no doubt more. It's just a couple of parens on either side. Look into your heart. You know it's the right call. > Function expressions, evals in SpiderMonkey > --- > > Key: COUCHDB-1397 > URL: https://issues.apache.org/jira/browse/COUCHDB-1397 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Affects Versions: 1.2.1 > Environment: All >Reporter: Jason Smith > > New SpiderMonkey releases do not eval() a sole anonymous function expression. > That is not a valid JavaScript statement, and so it is not a valid JavaScript > script. > COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for > 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.") -- 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-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199766#comment-13199766
]
Paul Joseph Davis commented on COUCHDB-1397:
Erm, I'd like to point out that the string "function(doc) {}" actually *is*
invalid JavaScript. Anonymous functions at global scope are specifically not
ok. Although anonymous functions in a statement context *are* ok. Its a subtle
distinction but its quite important.
Also, just today I came across a scenario of compiling a regular expression
outside the function scope as a valid use of the "helper" pattern.
> Function expressions, evals in SpiderMonkey
> ---
>
> Key: COUCHDB-1397
> URL: https://issues.apache.org/jira/browse/COUCHDB-1397
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 1.2.1
> Environment: All
>Reporter: Jason Smith
>
> New SpiderMonkey releases do not eval() a sole anonymous function expression.
> That is not a valid JavaScript statement, and so it is not a valid JavaScript
> script.
> COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
> 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.")
--
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-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199747#comment-13199747
]
James Howe commented on COUCHDB-1397:
-
There's nothing "Invalid" about this javascript: {"map": "function(doc) {}"},
it's only the way it's used (i.e. blindly eval'd) that is invalid. A
source-to-source translation cold be s/\bfunction\(/function map(/.
IMO, it is the people writing {"map": "var d=1; function(doc) { emit(doc._id,
d);"} that should find their code not working, as they are using undocumented
features.
If changes are to be made, I much prefer Benoit's suggestion - having "doc" be
implicit in the context and the value of "map" keys being function bodies.
"emit" already works like this, so makes no difference to JSLintability.
> Function expressions, evals in SpiderMonkey
> ---
>
> Key: COUCHDB-1397
> URL: https://issues.apache.org/jira/browse/COUCHDB-1397
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 1.2.1
> Environment: All
>Reporter: Jason Smith
>
> New SpiderMonkey releases do not eval() a sole anonymous function expression.
> That is not a valid JavaScript statement, and so it is not a valid JavaScript
> script.
> COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
> 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.")
--
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-1073) DELETE _session doesn't delete the session. Client can still get user information using GET _session and with the session cookie retrieved.
[ https://issues.apache.org/jira/browse/COUCHDB-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199718#comment-13199718 ] Robert Newson commented on COUCHDB-1073: DELETE _session returns a response that clears the clients AuthSession cookie. > DELETE _session doesn't delete the session. Client can still get user > information using GET _session and with the session cookie retrieved. > --- > > Key: COUCHDB-1073 > URL: https://issues.apache.org/jira/browse/COUCHDB-1073 > Project: CouchDB > Issue Type: Improvement >Reporter: Johnny Weng Luu > > When using DELETE _session CouchDB only sends a empty session cookie back. > But if I use the original session cookie when using GET _session I can still > get the user information. > https://gist.github.com/838996 > This could be a security flaw because when the user leaves the computer a > hacker can check out the session cookie and log in to account. > Very bad if it's a very sensitive web application like financial. > Isn't it better to just delete the session internally in couchdb when DELETE > _session is used. Then that session cookie the hacker gets won't matter > because the session is already gone. -- 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-1399) Rename _rev to _mvcc or _lock
[ https://issues.apache.org/jira/browse/COUCHDB-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199717#comment-13199717 ] Paul Joseph Davis commented on COUCHDB-1399: @Alexander Yes, all the other bits would need to be renamed to match the new name as well. I honestly don't care what it's renamed to as long as it doesn't have a revision connotation. @Dirkjan If by exceedingly limited you mean removes an entire class of misunderstanding in the community, then yes. :) But I do think this is something we should at least be considering. Also, I'm assuming that 2.0 will have other similarly large breaks in API so I don't see this as much of an issue since its mostly just a renaming of a concept (with no current plans at actually changing behavior). > Rename _rev to _mvcc or _lock > - > > Key: COUCHDB-1399 > URL: https://issues.apache.org/jira/browse/COUCHDB-1399 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Affects Versions: 2.0 >Reporter: Paul Joseph Davis > Fix For: 2.0 > > > We should rename the "revisions" to "lock" or "token" or some other suitably > opaque term so we stop getting people asking questions about treating them as > revisions. -- 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-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199714#comment-13199714 ] Paul Joseph Davis commented on COUCHDB-1397: @Jason I reject the premise that there's a distinction to be made between valid JavaScript and valid "CouchDB programming". At this point I would say that if its not possible to have whatever we decide pass jslint in a copy/paste manner, then its not valid anything. Also, the function body thing is the same thing I suggested as an aside except that the wrapping it in a function part is useless and will lead to more issues than it solves. Also, it has the same issues that if you did do it, the included code would be executed everytime (ie, if you pulled in a large helper it would redefine everything again (also note, this is not the same as compilation)). > Function expressions, evals in SpiderMonkey > --- > > Key: COUCHDB-1397 > URL: https://issues.apache.org/jira/browse/COUCHDB-1397 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Affects Versions: 1.2.1 > Environment: All >Reporter: Jason Smith > > New SpiderMonkey releases do not eval() a sole anonymous function expression. > That is not a valid JavaScript statement, and so it is not a valid JavaScript > script. > COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for > 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.") -- 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-1399) Rename _rev to _mvcc or _lock
[ https://issues.apache.org/jira/browse/COUCHDB-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199705#comment-13199705 ] Dirkjan Ochtman commented on COUCHDB-1399: -- This seems like exceedingly limited benefit for a big break in compatibility. I'd suggest the solution should be better docs, instead. > Rename _rev to _mvcc or _lock > - > > Key: COUCHDB-1399 > URL: https://issues.apache.org/jira/browse/COUCHDB-1399 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Affects Versions: 2.0 >Reporter: Paul Joseph Davis > Fix For: 2.0 > > > We should rename the "revisions" to "lock" or "token" or some other suitably > opaque term so we stop getting people asking questions about treating them as > revisions. -- 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-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199697#comment-13199697
]
Jason Smith commented on COUCHDB-1397:
--
@Paul
We really need to define "invalid JavaScript" and distinguish it from "invalid
CouchDB programming" which is why I wrote Fact #6.
For example, Benoit suggested that we could provide only the function *bodies*.
They are implicitly wrapped in a function(doc) { ... }. That's neat! In a world
where CouchDB had always worked that way, we would all call "emit(doc._id,
null)" *valid CouchDB* but we know it is invalid JavaScript (doc is unbound).
I take you to mean that "valid CouchDB" implies "valid JavaScript."
But valid CouchDB is more relaxing with anonymous functions ("invalid
JavaScript"). Business as usual is beautiful.
How could it be implemented on all SM versions? What if we catch the eval()? If
the error is "anonymous function at a top level scope" then we try again with
"("+code+")". Yes, it is a tiny source transformation, and that is bad; however
it is a common idiom in Javascript when building code from data.
(If you ask me, it is the helper function people who should see their code
broken; not we who have followed the customs and conventions all along. Thus I
prefer your original patch the most: wrap it in parens.)
> Function expressions, evals in SpiderMonkey
> ---
>
> Key: COUCHDB-1397
> URL: https://issues.apache.org/jira/browse/COUCHDB-1397
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 1.2.1
> Environment: All
>Reporter: Jason Smith
>
> New SpiderMonkey releases do not eval() a sole anonymous function expression.
> That is not a valid JavaScript statement, and so it is not a valid JavaScript
> script.
> COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
> 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.")
--
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-1073) DELETE _session doesn't delete the session. Client can still get user information using GET _session and with the session cookie retrieved.
[ https://issues.apache.org/jira/browse/COUCHDB-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199695#comment-13199695 ] Dave Cottlehuber commented on COUCHDB-1073: --- I discovered the same issue last night; still digging in the code but this just smells bad. What does DELETE _session actually do then? > DELETE _session doesn't delete the session. Client can still get user > information using GET _session and with the session cookie retrieved. > --- > > Key: COUCHDB-1073 > URL: https://issues.apache.org/jira/browse/COUCHDB-1073 > Project: CouchDB > Issue Type: Improvement >Reporter: Johnny Weng Luu > > When using DELETE _session CouchDB only sends a empty session cookie back. > But if I use the original session cookie when using GET _session I can still > get the user information. > https://gist.github.com/838996 > This could be a security flaw because when the user leaves the computer a > hacker can check out the session cookie and log in to account. > Very bad if it's a very sensitive web application like financial. > Isn't it better to just delete the session internally in couchdb when DELETE > _session is used. Then that session cookie the hacker gets won't matter > because the session is already gone. -- 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
How to connect couchdb through javascript
I am new to couchDB. I need a simple java script code for connecting CouchDB database and reading a document and displaying the content in the browser window. Please anyone help me. Thanks, Aruna -- View this message in context: http://couchdb-development.1959287.n2.nabble.com/How-to-connect-couchdb-through-javascript-tp7249589p7249589.html Sent from the CouchDB Development mailing list archive at Nabble.com.
[jira] [Commented] (COUCHDB-1399) Rename _rev to _mvcc or _lock
[ https://issues.apache.org/jira/browse/COUCHDB-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199678#comment-13199678 ] Alexander Shorin commented on COUCHDB-1399: --- Would `_state` name be more convenient? May be I'm wrong, but I'd like to count `_rev` as document state id, because it's better describes functional of this field: last document state, conflict document states etc. Also, there are `_revisions` and `_attachments/revpos` fields that should be noticed too as well as `db/_rev_count` resource and `rev`, `rev_info`, `open_revs` document resource parameters. Have I missed something? > Rename _rev to _mvcc or _lock > - > > Key: COUCHDB-1399 > URL: https://issues.apache.org/jira/browse/COUCHDB-1399 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Affects Versions: 2.0 >Reporter: Paul Joseph Davis > Fix For: 2.0 > > > We should rename the "revisions" to "lock" or "token" or some other suitably > opaque term so we stop getting people asking questions about treating them as > revisions. -- 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-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199668#comment-13199668
]
Paul Joseph Davis commented on COUCHDB-1397:
@Jason
Of course I'd look at a patch if you have one. Though as I've mentioned before,
anything that relies on parsing JavaScript or other source-to-source transforms
is going to be heavily discouraged. Also, while I understand that this will
change things from the old method, I'm not overly swayed by the relaxing
arguments here. Fact of the matter is that this is invalid JavaScript, so
regardless of what we do, it should at least be valid JavaScript. (And jslint
and other command line tools would finally start working as well).
@Jason, @Max, @James
I tried doing some hacky shortcuts to account for this. Specifically, "(" +
map_source + ")" because the "error" is literally "anonymous function at top
level scope" or some such and the parens make it kosher. But this ends up
breaking all of the code that looks like "var f = 1; function(doc)
{emit(doc._id, f);};" which is a noticeable amount of JavaScript.
@Jason, @Max, @James
I did just think of an alternative solution which would be to make the new
version use scripts instead of functions. The resulting syntax would be
something like:
"var doc = next_doc(); emit(doc._id, null)"
Which would then just be executed once for every doc. Though going this route,
we'd need some sort of context for the functions so people could precompile
their CommonJS libs and the like.
> Function expressions, evals in SpiderMonkey
> ---
>
> Key: COUCHDB-1397
> URL: https://issues.apache.org/jira/browse/COUCHDB-1397
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 1.2.1
> Environment: All
>Reporter: Jason Smith
>
> New SpiderMonkey releases do not eval() a sole anonymous function expression.
> That is not a valid JavaScript statement, and so it is not a valid JavaScript
> script.
> COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
> 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.")
--
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] [Created] (COUCHDB-1399) Rename _rev to _mvcc or _lock
Rename _rev to _mvcc or _lock - Key: COUCHDB-1399 URL: https://issues.apache.org/jira/browse/COUCHDB-1399 Project: CouchDB Issue Type: Improvement Components: Database Core Affects Versions: 2.0 Reporter: Paul Joseph Davis Fix For: 2.0 We should rename the "revisions" to "lock" or "token" or some other suitably opaque term so we stop getting people asking questions about treating them as revisions. -- 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
SV: backport of couchdb
Hi again everyone, I am happy to get a discussion going about this. I'd say Debian is a major platform for servers. Therefor, I believe CouchDB should exist there - with a reasonable modern version. Sure, you can install from source. However, with CouchDB and it's replication features it should be easy to roll it out to a multitude of Debian servers and kick off replication. Also, previously Couchbase was hosting a (sadly, buggy) Debian package. After the death of the Couchbase package[1] there is no modern Debian package alternative anymore. To keep this discussion going - what did you think of Jan's proposal to set up a Debian maintainer mailing list? As of the initial question, shall Debian stable installations be living with 0.11 for another ~6 months? I guess so. /J -Ursprungligt meddelande- Från: Jan Lehnardt [mailto:j...@apache.org] Skickat: den 31 januari 2012 21:42 Till: dev@couchdb.apache.org Kopia: Laszlo Boszormenyi Ämne: Re: backport of couchdb Hi Laszlo, On Jan 31, 2012, at 21:24 , Laszlo Boszormenyi wrote: > Hi, > > First, I'm an official DD and the maintainer of CouchDB. Pleased to meet you and thanks for weighing in on this discussion :) >> As for the back porting, Debian doesn't directly manage any packages. >> Everything has a package maintainer who may or may not be part of the >> Debian staff, so it really does land on the maintainer. And I don't >> see how you could back port fixes from, say, 1.x.x to 0.x.x. > Let me ask an other way. Is CouchDB expected to change a lot > internally? I think it is. The question, I think, is how much end-users will be affected by these changes (upgrade trouble, incompatibilities etc.) We are doing our best to not break BC (according to semver.org) and make upgrades seamless and well documented. > What about helping downstream with security fixes? We could start a new mailing list package-maintain...@couchdb.apache.org where downstream folks can subscribe and get notified about impeding releases as well as security notices. Would that be a good first step? What else could we do to help you downstream? > When CouchDB 1.2.0 is expected to be released? We are expecting to call a vote in the next few days (pending release manager time). As per our process, it'll take 4-5 days after the initial call for voting to get the release out (if the votes don't go through and if issues are found, this process is reset). Let us know if you have any other questions and thanks again for helping out! Cheers Jan --
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199616#comment-13199616 ] James Howe commented on COUCHDB-1397: - For Paul's example alternatives, is it not a trivial operation to convert the old format to these internally before eval? Then users can do what they've always done (and don't have to worry about new ways to ty[po) and the SM-related problem is solved. > Function expressions, evals in SpiderMonkey > --- > > Key: COUCHDB-1397 > URL: https://issues.apache.org/jira/browse/COUCHDB-1397 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Affects Versions: 1.2.1 > Environment: All >Reporter: Jason Smith > > New SpiderMonkey releases do not eval() a sole anonymous function expression. > That is not a valid JavaScript statement, and so it is not a valid JavaScript > script. > COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for > 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.") -- 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
