[jira] Commented: (COUCHDB-947) /_restart API requires "Content-Type: application/json"
[ https://issues.apache.org/jira/browse/COUCHDB-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932204#action_12932204 ] Jan Lehnardt commented on COUCHDB-947: -- I take my previous statement back and pronounce the opposite. The reason is any website could restart your local CouchDB (or any CouchDB under a well known URL) by sending a form submit to that URL. By requiring the Content-Type to be application/json, we ensure an HTML form can't do this. It's inconvenient, but required. Sorry. > /_restart API requires "Content-Type: application/json" > --- > > Key: COUCHDB-947 > URL: https://issues.apache.org/jira/browse/COUCHDB-947 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Affects Versions: 1.1, 1.2 > Environment: Mac OS X 10.6.5 >Reporter: Filippo Fadda > Fix For: 1.0.1, 1.1, 1.2 > > > The "/_restart" API requires "Content-Type: application/json" header. This is > not coherent because the API doesn't need parameters to be passed using JSON. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-947) /_restart API requires "Content-Type: application/json"
[ https://issues.apache.org/jira/browse/COUCHDB-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932180#action_12932180 ] Jan Lehnardt commented on COUCHDB-947: -- I think it is safe to remove the requirement to pass in the Content-Type, since no data is actually stored. > /_restart API requires "Content-Type: application/json" > --- > > Key: COUCHDB-947 > URL: https://issues.apache.org/jira/browse/COUCHDB-947 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Affects Versions: 1.1, 1.2 > Environment: Mac OS X 10.6.5 >Reporter: Filippo Fadda > Fix For: 1.0.1, 1.1, 1.2 > > > The "/_restart" API requires "Content-Type: application/json" header. This is > not coherent because the API doesn't need parameters to be passed using JSON. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-948) Breadcrumb doesn't need to be URI encoded
[ https://issues.apache.org/jira/browse/COUCHDB-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt closed COUCHDB-948. Resolution: Fixed > Breadcrumb doesn't need to be URI encoded > - > > Key: COUCHDB-948 > URL: https://issues.apache.org/jira/browse/COUCHDB-948 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 1.1 >Reporter: Gabriel Farrell >Priority: Trivial > Fix For: 1.0.2, 1.1 > > Attachments: noEncode.diff > > > Introduced by github commit 871e2617 on 2010-11-02. When I go to the design > doc "foo" for db "bob", breadcrumbs/nav shows "Overview > bob > > _design%2Ffoo" when it should be "Overview > bob > _design/foo". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-948) Breadcrumb doesn't need to be URI encoded
[ https://issues.apache.org/jira/browse/COUCHDB-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932179#action_12932179 ] Jan Lehnardt commented on COUCHDB-948: -- We can't allow arbitrary characters from a URL parameter to be written into the HTML without escaping. Since doc ids need to escape URL chars (except the / in design docs) anyway, I think the current way is the best solution. > Breadcrumb doesn't need to be URI encoded > - > > Key: COUCHDB-948 > URL: https://issues.apache.org/jira/browse/COUCHDB-948 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 1.1 >Reporter: Gabriel Farrell >Priority: Trivial > Fix For: 1.0.2, 1.1 > > Attachments: noEncode.diff > > > Introduced by github commit 871e2617 on 2010-11-02. When I go to the design > doc "foo" for db "bob", breadcrumbs/nav shows "Overview > bob > > _design%2Ffoo" when it should be "Overview > bob > _design/foo". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-912) Anonymous Access to Design Docs on private DB's
[ https://issues.apache.org/jira/browse/COUCHDB-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932178#action_12932178 ] Jan Lehnardt commented on COUCHDB-912: -- Do I read this correctly as the config option couch_httpd_auth/anonymous_design_doc will expose any design document in a protected database to anonymous users? This seems a tad coarse to me. It wouldn't make things simpler, but I'd expect either design docs having a property allowing anonymous reads or at least a database's secObj could hold a list of aon-public design documents. > Anonymous Access to Design Docs on private DB's > --- > > Key: COUCHDB-912 > URL: https://issues.apache.org/jira/browse/COUCHDB-912 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface >Reporter: Dale Harvey > Attachments: anon.patch > > > Right now people need to go through futon in order to login to couchapps > running on private databases, this is a pretty big limitation on the type of > couchapps that can be built > Propose adding the ability for users to flag the design docs as readable for > anonymous users, could be implemented though an attribute on the design doc? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-798) Compile mochijson2 down to native code
[ https://issues.apache.org/jira/browse/COUCHDB-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932169#action_12932169 ] Randall Leeds commented on COUCHDB-798: --- +1 on both accounts I'm a little nervous about turning this on by default anywhere. While I wish we could just be optimistic it's important for us to be conservative especially when we don't have comprehensive testing across a grid of OS/Erlang combinations, HiPE/regular, etc. But *I'd* like to turn it on in selective places for my own builds. On the other hand, making it default for mochijson in the absence of any flags seems like a reasonable thing to do on trunk, maybe just after the next release so it can bake a while. I think Adam's reasoning is sound about it being a pretty innocuous, but important, part of the code to have running with native speedups. > Compile mochijson2 down to native code > -- > > Key: COUCHDB-798 > URL: https://issues.apache.org/jira/browse/COUCHDB-798 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Reporter: Adam Kocoloski > Fix For: 1.2 > > > Adding a -compile(native) flag to mochijson2.erl results in a marked > performance improvement for large documents. I did the following test > node compare_write.js -u http://127.0.0.1:5984 -v http://127.0.0.1:5985 -1 > trunk -2 mochijson2-native -d large -r 2 -t 90 -c 200 > and got the results at [1]. The graph shows that the average client response > time dropped by about 35% with the native encoder. Qualitatively, I also > noticed that the native encoder used substantially fewer CPU cycles. On my > dual core Macbook, idle CPU went from ~10% on trunk to ~25% with the +native > version while the test was running. > Running the same test with small documents showed essentially no difference > between the two comparatives, which is not surprising. > A potential downside of +native is instability in the VM. I've encountered > issues on AMD machines with R13B04 when using +native for all modules, and > the core dump pointed to an issue in HiPE. On the other hand, I think that > mochijson2 should work very well as native code, since it doesn't do any > message passing or I/O. I'm +1 on simply adding the compile option to the > codebase in trunk to see how it behaves. > [1]: > http://mikeal.couchone.com/graphs/_design/app/_show/compareWriteTest/e69057a29bd6e4ac4ae0115fac00ae50 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-947) /_restart API requires "Content-Type: application/json"
[ https://issues.apache.org/jira/browse/COUCHDB-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filippo Fadda updated COUCHDB-947: -- Fix Version/s: 1.0.1 1.1 Affects Version/s: (was: 1.0.1) 1.2 1.1 > /_restart API requires "Content-Type: application/json" > --- > > Key: COUCHDB-947 > URL: https://issues.apache.org/jira/browse/COUCHDB-947 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Affects Versions: 1.1, 1.2 > Environment: Mac OS X 10.6.5 >Reporter: Filippo Fadda > Fix For: 1.0.1, 1.1, 1.2 > > > The "/_restart" API requires "Content-Type: application/json" header. This is > not coherent because the API doesn't need parameters to be passed using JSON. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-946) Calling the "/_restart" API via socket or cURL, sometimes CouchDB restarts before I can get the response headers.
[
https://issues.apache.org/jira/browse/COUCHDB-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filippo Fadda updated COUCHDB-946:
--
Fix Version/s: 1.0.1
1.1
Affects Version/s: (was: 1.0.1)
1.2
1.1
> Calling the "/_restart" API via socket or cURL, sometimes CouchDB restarts
> before I can get the response headers.
> -
>
> Key: COUCHDB-946
> URL: https://issues.apache.org/jira/browse/COUCHDB-946
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.1, 1.2
> Environment: Mac OS X 10.6.5
>Reporter: Filippo Fadda
> Fix For: 1.0.1, 1.1, 1.2
>
>
> Calling the "/_restart" API via socket or cURL, sometimes CouchDB restarts
> before I can get the response headers. Not always, sometimes.
> Additionally, with a restart cycle, calling the API sequentially, sometimes
> CouchDB crashes with a "bus error" or "seg fault".
>
> /_restart
>
> _ using socket _
> string(6) "200 OK"
> array(5) {
> ["Server"]=>
> string(31) "CouchDB/1.0.1 (Erlang OTP/R14B)"
> ["Date"]=>
> string(29) "Fri, 12 Nov 2010 04:07:47 GMT"
> ["Content-Type"]=>
> string(24) "text/plain;charset=utf-8"
> ["Content-Length"]=>
> string(2) "12"
> ["Cache-Control"]=>
> string(15) "must-revalidate"
> }
>
> /_restart
>
> _ using socket _
> Error code: 0
> Message: HTTP Status Code undefined.
>
> /_restart
>
> _ using cURL _
> string(6) "200 OK"
> array(5) {
> ["Server"]=>
> string(31) "CouchDB/1.0.1 (Erlang OTP/R14B)"
> ["Date"]=>
> string(29) "Fri, 12 Nov 2010 04:13:04 GMT"
> ["Content-Type"]=>
> string(24) "text/plain;charset=utf-8"
> ["Content-Length"]=>
> string(2) "12"
> ["Cache-Control"]=>
> string(15) "must-revalidate"
> }
>
> /_restart
>
> _ using cURL _
> Error code: 0
> Message: Empty reply from server
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-947) /_restart API requires "Content-Type: application/json"
[ https://issues.apache.org/jira/browse/COUCHDB-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filippo Fadda updated COUCHDB-947: -- Fix Version/s: 1.2 > /_restart API requires "Content-Type: application/json" > --- > > Key: COUCHDB-947 > URL: https://issues.apache.org/jira/browse/COUCHDB-947 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Affects Versions: 1.0.1 > Environment: Mac OS X 10.6.5 >Reporter: Filippo Fadda > Fix For: 1.2 > > > The "/_restart" API requires "Content-Type: application/json" header. This is > not coherent because the API doesn't need parameters to be passed using JSON. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-946) Calling the "/_restart" API via socket or cURL, sometimes CouchDB restarts before I can get the response headers.
[
https://issues.apache.org/jira/browse/COUCHDB-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filippo Fadda updated COUCHDB-946:
--
Fix Version/s: 1.2
> Calling the "/_restart" API via socket or cURL, sometimes CouchDB restarts
> before I can get the response headers.
> -
>
> Key: COUCHDB-946
> URL: https://issues.apache.org/jira/browse/COUCHDB-946
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.0.1
> Environment: Mac OS X 10.6.5
>Reporter: Filippo Fadda
> Fix For: 1.2
>
>
> Calling the "/_restart" API via socket or cURL, sometimes CouchDB restarts
> before I can get the response headers. Not always, sometimes.
> Additionally, with a restart cycle, calling the API sequentially, sometimes
> CouchDB crashes with a "bus error" or "seg fault".
>
> /_restart
>
> _ using socket _
> string(6) "200 OK"
> array(5) {
> ["Server"]=>
> string(31) "CouchDB/1.0.1 (Erlang OTP/R14B)"
> ["Date"]=>
> string(29) "Fri, 12 Nov 2010 04:07:47 GMT"
> ["Content-Type"]=>
> string(24) "text/plain;charset=utf-8"
> ["Content-Length"]=>
> string(2) "12"
> ["Cache-Control"]=>
> string(15) "must-revalidate"
> }
>
> /_restart
>
> _ using socket _
> Error code: 0
> Message: HTTP Status Code undefined.
>
> /_restart
>
> _ using cURL _
> string(6) "200 OK"
> array(5) {
> ["Server"]=>
> string(31) "CouchDB/1.0.1 (Erlang OTP/R14B)"
> ["Date"]=>
> string(29) "Fri, 12 Nov 2010 04:13:04 GMT"
> ["Content-Type"]=>
> string(24) "text/plain;charset=utf-8"
> ["Content-Length"]=>
> string(2) "12"
> ["Cache-Control"]=>
> string(15) "must-revalidate"
> }
>
> /_restart
>
> _ using cURL _
> Error code: 0
> Message: Empty reply from server
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-798) Compile mochijson2 down to native code
[ https://issues.apache.org/jira/browse/COUCHDB-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932108#action_12932108 ] Paul Joseph Davis commented on COUCHDB-798: --- I wonder if we can do a middle ground thing between all native and none native controlled by a ./configure parameter like --native-modules or some such. Seems like it'd be easy enough to add an erlc flag and ifdef the -compile(native) directive. > Compile mochijson2 down to native code > -- > > Key: COUCHDB-798 > URL: https://issues.apache.org/jira/browse/COUCHDB-798 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Reporter: Adam Kocoloski > Fix For: 1.2 > > > Adding a -compile(native) flag to mochijson2.erl results in a marked > performance improvement for large documents. I did the following test > node compare_write.js -u http://127.0.0.1:5984 -v http://127.0.0.1:5985 -1 > trunk -2 mochijson2-native -d large -r 2 -t 90 -c 200 > and got the results at [1]. The graph shows that the average client response > time dropped by about 35% with the native encoder. Qualitatively, I also > noticed that the native encoder used substantially fewer CPU cycles. On my > dual core Macbook, idle CPU went from ~10% on trunk to ~25% with the +native > version while the test was running. > Running the same test with small documents showed essentially no difference > between the two comparatives, which is not surprising. > A potential downside of +native is instability in the VM. I've encountered > issues on AMD machines with R13B04 when using +native for all modules, and > the core dump pointed to an issue in HiPE. On the other hand, I think that > mochijson2 should work very well as native code, since it doesn't do any > message passing or I/O. I'm +1 on simply adding the compile option to the > codebase in trunk to see how it behaves. > [1]: > http://mikeal.couchone.com/graphs/_design/app/_show/compareWriteTest/e69057a29bd6e4ac4ae0115fac00ae50 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: scripts in [update_notification] section ?
On 11/15/2010 04:58 PM, Zachary Zolton wrote: I think your update notification script is not supposed to exit every time there's a change. It's supposed to stay running in a loop where you get the next line from standard input (for each update), only quitting when that stream gets closed. You're right, it should read from the input and stay in the loop as the example shows. I adpted and tested the script and it seems to work. Thanks, cdrx
Re: scripts in [update_notification] section ?
On 15 Nov 2010, at 16:58, Zachary Zolton wrote: > I think your update notification script is not supposed to exit every > time there's a change. It's supposed to stay running in a loop where > you get the next line from standard input (for each update), only > quitting when that stream gets closed. That is correct. > That said, the update notification feature should generally be > considered deprecated by the newer changes API: > http://guide.couchdb.org/draft/notifications.html That is not correct :) — The two APIs serve different purposes and none of them is deprecated. That said, a /_db_update handler that acts like DbUpdateNotification but over HTTP would be neat. Cheers Jan -- > > Cheers, > Zach > > On Mon, Nov 15, 2010 at 9:26 AM, cdr53x wrote: >> Hi, >> >> I read the article concerning the view updates in the wiki >> (http://wiki.apache.org/couchdb/Regenerating_views_on_update) and tried to >> test this. >> >> I just put a basic script that simply logs a message in my conf.ini : >> >> [update_notification] >> view_update=/home/tests/couchdb/deployed/bin/update_views.rb >> >> After restarting couch, I noticed that this script is invoked _all_ the >> time, i.e as soons as the script finishes couch starts another one. And no >> insertions/updates are performed on the db. >> >> So there seems to be no relation between the script execution and the fact >> that a document has been inserted or updated. >> >> Is this the expected behavior or a bug ? >> >> Regards, >> >> cdrx >> >>
[jira] Reopened: (COUCHDB-948) Breadcrumb doesn't need to be URI encoded
[ https://issues.apache.org/jira/browse/COUCHDB-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Farrell reopened COUCHDB-948: - The change committed addresses the particular case of forward slashes in doc IDs, but you're still URI encoding anything else outside alphanumeric. A document ID such as "1+1=2" shows up as such in the doc listings on the database page, but in the breadcrumb on the document page it's "1%2B1%3D2". Is there any reason to URI encode that text? It's a string in a element and in my tests it gets properly HTML escaped without wrapping it in encodeURIcomponent. > Breadcrumb doesn't need to be URI encoded > - > > Key: COUCHDB-948 > URL: https://issues.apache.org/jira/browse/COUCHDB-948 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 1.1 >Reporter: Gabriel Farrell >Priority: Trivial > Fix For: 1.0.2, 1.1 > > Attachments: noEncode.diff > > > Introduced by github commit 871e2617 on 2010-11-02. When I go to the design > doc "foo" for db "bob", breadcrumbs/nav shows "Overview > bob > > _design%2Ffoo" when it should be "Overview > bob > _design/foo". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: scripts in [update_notification] section ?
I think your update notification script is not supposed to exit every time there's a change. It's supposed to stay running in a loop where you get the next line from standard input (for each update), only quitting when that stream gets closed. That said, the update notification feature should generally be considered deprecated by the newer changes API: http://guide.couchdb.org/draft/notifications.html Cheers, Zach On Mon, Nov 15, 2010 at 9:26 AM, cdr53x wrote: > Hi, > > I read the article concerning the view updates in the wiki > (http://wiki.apache.org/couchdb/Regenerating_views_on_update) and tried to > test this. > > I just put a basic script that simply logs a message in my conf.ini : > > [update_notification] > view_update=/home/tests/couchdb/deployed/bin/update_views.rb > > After restarting couch, I noticed that this script is invoked _all_ the > time, i.e as soons as the script finishes couch starts another one. And no > insertions/updates are performed on the db. > > So there seems to be no relation between the script execution and the fact > that a document has been inserted or updated. > > Is this the expected behavior or a bug ? > > Regards, > > cdrx > >
[jira] Updated: (COUCHDB-912) Anonymous Access to Design Docs on private DB's
[ https://issues.apache.org/jira/browse/COUCHDB-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-912: Attachment: anon.patch > Anonymous Access to Design Docs on private DB's > --- > > Key: COUCHDB-912 > URL: https://issues.apache.org/jira/browse/COUCHDB-912 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface >Reporter: Dale Harvey > Attachments: anon.patch > > > Right now people need to go through futon in order to login to couchapps > running on private databases, this is a pretty big limitation on the type of > couchapps that can be built > Propose adding the ability for users to flag the design docs as readable for > anonymous users, could be implemented though an attribute on the design doc? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-912) Anonymous Access to Design Docs on private DB's
[ https://issues.apache.org/jira/browse/COUCHDB-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-912: Attachment: (was: anon.patch) > Anonymous Access to Design Docs on private DB's > --- > > Key: COUCHDB-912 > URL: https://issues.apache.org/jira/browse/COUCHDB-912 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface >Reporter: Dale Harvey > > Right now people need to go through futon in order to login to couchapps > running on private databases, this is a pretty big limitation on the type of > couchapps that can be built > Propose adding the ability for users to flag the design docs as readable for > anonymous users, could be implemented though an attribute on the design doc? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
scripts in [update_notification] section ?
Hi, I read the article concerning the view updates in the wiki (http://wiki.apache.org/couchdb/Regenerating_views_on_update) and tried to test this. I just put a basic script that simply logs a message in my conf.ini : [update_notification] view_update=/home/tests/couchdb/deployed/bin/update_views.rb After restarting couch, I noticed that this script is invoked _all_ the time, i.e as soons as the script finishes couch starts another one. And no insertions/updates are performed on the db. So there seems to be no relation between the script execution and the fact that a document has been inserted or updated. Is this the expected behavior or a bug ? Regards, cdrx
[jira] Updated: (COUCHDB-912) Anonymous Access to Design Docs on private DB's
[ https://issues.apache.org/jira/browse/COUCHDB-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-912: Attachment: anon.patch > Anonymous Access to Design Docs on private DB's > --- > > Key: COUCHDB-912 > URL: https://issues.apache.org/jira/browse/COUCHDB-912 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface >Reporter: Dale Harvey > Attachments: anon.patch > > > Right now people need to go through futon in order to login to couchapps > running on private databases, this is a pretty big limitation on the type of > couchapps that can be built > Propose adding the ability for users to flag the design docs as readable for > anonymous users, could be implemented though an attribute on the design doc? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-912) Anonymous Access to Design Docs on private DB's
[ https://issues.apache.org/jira/browse/COUCHDB-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-912: Attachment: (was: anon.patch) > Anonymous Access to Design Docs on private DB's > --- > > Key: COUCHDB-912 > URL: https://issues.apache.org/jira/browse/COUCHDB-912 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface >Reporter: Dale Harvey > Attachments: anon.patch > > > Right now people need to go through futon in order to login to couchapps > running on private databases, this is a pretty big limitation on the type of > couchapps that can be built > Propose adding the ability for users to flag the design docs as readable for > anonymous users, could be implemented though an attribute on the design doc? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-912) Anonymous Access to Design Docs on private DB's
[ https://issues.apache.org/jira/browse/COUCHDB-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932075#action_12932075 ] Dale Harvey commented on COUCHDB-912: - Thanks for the advice Filipe, very helpful made those changes (the javascript is 2 space indented, just was a bug in one of the declarations which is fixed) I can merge the test into another suite if anyone would prefer that, just cleaner in a seperate one for now as it does a run_on_modified_server (that could be taken out as I would propose for this to be the default, I wasnt sure about the best practice for that though) > Anonymous Access to Design Docs on private DB's > --- > > Key: COUCHDB-912 > URL: https://issues.apache.org/jira/browse/COUCHDB-912 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface >Reporter: Dale Harvey > Attachments: anon.patch > > > Right now people need to go through futon in order to login to couchapps > running on private databases, this is a pretty big limitation on the type of > couchapps that can be built > Propose adding the ability for users to flag the design docs as readable for > anonymous users, could be implemented though an attribute on the design doc? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-912) Anonymous Access to Design Docs on private DB's
[ https://issues.apache.org/jira/browse/COUCHDB-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-912: Attachment: anon.patch > Anonymous Access to Design Docs on private DB's > --- > > Key: COUCHDB-912 > URL: https://issues.apache.org/jira/browse/COUCHDB-912 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface >Reporter: Dale Harvey > Attachments: anon.patch > > > Right now people need to go through futon in order to login to couchapps > running on private databases, this is a pretty big limitation on the type of > couchapps that can be built > Propose adding the ability for users to flag the design docs as readable for > anonymous users, could be implemented though an attribute on the design doc? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-912) Anonymous Access to Design Docs on private DB's
[ https://issues.apache.org/jira/browse/COUCHDB-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-912: Attachment: (was: attachment_permissions.js) > Anonymous Access to Design Docs on private DB's > --- > > Key: COUCHDB-912 > URL: https://issues.apache.org/jira/browse/COUCHDB-912 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface >Reporter: Dale Harvey > > Right now people need to go through futon in order to login to couchapps > running on private databases, this is a pretty big limitation on the type of > couchapps that can be built > Propose adding the ability for users to flag the design docs as readable for > anonymous users, could be implemented though an attribute on the design doc? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-912) Anonymous Access to Design Docs on private DB's
[ https://issues.apache.org/jira/browse/COUCHDB-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-912: Attachment: (was: anon.patch) > Anonymous Access to Design Docs on private DB's > --- > > Key: COUCHDB-912 > URL: https://issues.apache.org/jira/browse/COUCHDB-912 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface >Reporter: Dale Harvey > Attachments: attachment_permissions.js > > > Right now people need to go through futon in order to login to couchapps > running on private databases, this is a pretty big limitation on the type of > couchapps that can be built > Propose adding the ability for users to flag the design docs as readable for > anonymous users, could be implemented though an attribute on the design doc? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-629) futon doesn't raise a popup anymore to ask for login if needed
[ https://issues.apache.org/jira/browse/COUCHDB-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932069#action_12932069 ] Jan Lehnardt commented on COUCHDB-629: -- Isn't it that you just have to uncomment the `;WWW-Authenticate = Basic realm="administrator"` line in local.ini? > futon doesn't raise a popup anymore to ask for login if needed > -- > > Key: COUCHDB-629 > URL: https://issues.apache.org/jira/browse/COUCHDB-629 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 0.11 >Reporter: Benoit Chesneau > > Since latest change, futon doesn't raised a window to ask for login if needed. > Steps to reproduce : > try to delete a db with an admin user set, you only get "The database could > not be deleted: You are not a server admin." message. It would be more > intuitive to raise popup or something that ask for a login. Here I lost some > time to understand what to do. Especially since login was at the bottom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-584) Remote Replication with HTTP Auth fails on design docs
[
https://issues.apache.org/jira/browse/COUCHDB-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt closed COUCHDB-584.
Resolution: Fixed
Fix Version/s: 1.0
This should be fixed. Please reopen if it persists.
> Remote Replication with HTTP Auth fails on design docs
> --
>
> Key: COUCHDB-584
> URL: https://issues.apache.org/jira/browse/COUCHDB-584
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.10
>Reporter: Christian Stocker
>Assignee: Adam Kocoloski
> Fix For: 1.0
>
>
> I try to replicate a database with design documents. It fails on it. Here's
> the log from the server
> [info] [<0.4462.0>] 195.226.16.50 - - 'GET'
> /mydatabase/_changes?style=all_docs&heartbeat=true&since=0&feed=normal 200
> [info] [<0.4463.0>] 195.226.16.50 - - 'GET'
> /mydatabase/_design%2Fmydesign?open_revs=["3-ce4179d8efd6132c211d95e858619051"]&revs=true&latest=true
> 301
> [info] [<0.4465.0>] 195.226.16.50 - - 'GET'
> /mydatabase/_design/mydesign?open_revs=["3-ce4179d8efd6132c211d95e858619051"]&revs=true&latest=true_design%2Fmydesign?open_revs=["3-ce4179d8efd6132c211d95e858619051"]&revs=true&latest=true
> 401
> Looks like the redirect doesn't send the auth parameters on the second
> attempt (and the URL looks fishy too, but it works from the browser with the
> correct auth parameters)
> I start the replication with
> curl -X POST http://127.0.0.1:5984/_replicate -d
> '{"source":"http://admin:**...@example.org:5984/mydatabase/";,
> "target":"mydatabase_rep"}'
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-798) Compile mochijson2 down to native code
[ https://issues.apache.org/jira/browse/COUCHDB-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-798: --- Fix Version/s: (was: 1.1) 1.2 I'd rather put this in trunk for a while before it lands in a release. > Compile mochijson2 down to native code > -- > > Key: COUCHDB-798 > URL: https://issues.apache.org/jira/browse/COUCHDB-798 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Reporter: Adam Kocoloski > Fix For: 1.2 > > > Adding a -compile(native) flag to mochijson2.erl results in a marked > performance improvement for large documents. I did the following test > node compare_write.js -u http://127.0.0.1:5984 -v http://127.0.0.1:5985 -1 > trunk -2 mochijson2-native -d large -r 2 -t 90 -c 200 > and got the results at [1]. The graph shows that the average client response > time dropped by about 35% with the native encoder. Qualitatively, I also > noticed that the native encoder used substantially fewer CPU cycles. On my > dual core Macbook, idle CPU went from ~10% on trunk to ~25% with the +native > version while the test was running. > Running the same test with small documents showed essentially no difference > between the two comparatives, which is not surprising. > A potential downside of +native is instability in the VM. I've encountered > issues on AMD machines with R13B04 when using +native for all modules, and > the core dump pointed to an issue in HiPE. On the other hand, I think that > mochijson2 should work very well as native code, since it doesn't do any > message passing or I/O. I'm +1 on simply adding the compile option to the > codebase in trunk to see how it behaves. > [1]: > http://mikeal.couchone.com/graphs/_design/app/_show/compareWriteTest/e69057a29bd6e4ac4ae0115fac00ae50 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Next Release
On Nov 14, 2010, at 7:59 PM, Jan Lehnardt wrote: > > On 13 Nov 2010, at 18:55, Jan Lehnardt wrote: > >> >> >> On 13.11.2010, at 00:06, Noah Slater wrote: >> >>> >>> On 12 Nov 2010, at 20:26, Adam Kocoloski wrote: >>> We need to do better than that. I think part of the problem is that very few of us have the privileges to edit milestones. I wanted to jot down a couple of tickets with a FixFor of CouchDB 2.0, but then realized I couldn't make a 2.0 release and moved on to something else. Any reason we can't extend that level of access to committers? Best, >>> >>> At the moment, only me and Jan have access to that. >>> >>> I see no harm in opening it up on an individual basis to committers who >>> want it. >> >> Wait what do I? :) — I too think it's safe to open this to all committers. > > I've now added all committers to the JIRA admin staff. > > Cheers > Jan > -- > Thanks Jan!
[jira] Closed: (COUCHDB-948) Breadcrumb doesn't need to be URI encoded
[ https://issues.apache.org/jira/browse/COUCHDB-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt closed COUCHDB-948. Resolution: Fixed Fix Version/s: 1.1 1.0.2 > Breadcrumb doesn't need to be URI encoded > - > > Key: COUCHDB-948 > URL: https://issues.apache.org/jira/browse/COUCHDB-948 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 1.1 >Reporter: Gabriel Farrell >Priority: Trivial > Fix For: 1.0.2, 1.1 > > Attachments: noEncode.diff > > > Introduced by github commit 871e2617 on 2010-11-02. When I go to the design > doc "foo" for db "bob", breadcrumbs/nav shows "Overview > bob > > _design%2Ffoo" when it should be "Overview > bob > _design/foo". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Release 1.0.2
On Mon, Nov 15, 2010 at 10:49 AM, Matthew Sinclair-Day wrote: > On 11/15/10 at 7:11 PM, j...@apache.org (Jan Lehnardt) wrote: > > Looking at the issue list tagged for 1.0.2, I didn't see any mention of > fixes for chunked encoding and other things around HTTP protocol support. > Are those fixes going to be in 1.0.2? If you're referring to the replication issues, yes. https://issues.apache.org/jira/browse/COUCHDB-491 > > Matt > > -- Filipe David Manana, fdman...@gmail.com, fdman...@apache.org "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
Re: Release 1.0.2
On 11/15/10 at 7:11 PM, j...@apache.org (Jan Lehnardt) wrote: On 12 Nov 2010, at 20:21, Dirkjan Ochtman wrote: On Wed, Nov 3, 2010 at 18:06, Filipe David Manana wrote: and done Oh, look, I'm back for more nagging! How are we doing on 1.0.2? Or 1.1, for that matter, just any release that gets me the good stuff you've all been working on. JIRA lists a few open issues for 1.0.2: http://s.apache.org/couchdb-open-issues-1.0.2 I started going through and closed / applied / deferred a few to my best judgement, but if you (everybody here) could help me squashing this list, we'll be good. Likewise, if you think any issue not on this list should be considered, set its "Fix Version" to "1.0.2" so we can have a look. Other than that, NEWS & CHANGES need to be updated, if anyone wants to tackle this. Cheers Jan Looking at the issue list tagged for 1.0.2, I didn't see any mention of fixes for chunked encoding and other things around HTTP protocol support. Are those fixes going to be in 1.0.2? Matt
Change filters and heartbeats
Hi,
I think this issue was raised a couple months ago but I am not
sure what, if anything, has been done to address it or even
whether it was formally entered into JIRA.
Given the push for a 1.0.2 release, I wanted to raise it as an
issue for consideration for the 1.0.2 release.
The problem is basically this: when a change filter is busy
processing documents, the heartbeat will not be sent across the
wire. This plays havoc with clients listening on those feeds
because the sockets can eventually time out.
This might seem like an unlikely pathological situation, but
consider a network of couch servers front ended by one or more
application servers. The app servers listen on change
notifications to pick up messages from other apps/couch
servers. An app server does not want to "read" its own writes,
and so a filter is used.
In a busy system in which one server is producing most or all of
the documents, the change feed can die quickly and often.
In a busy system, this failure mode can have unintended
consequences by creating feedback loops on the app and database
servers, as well as the system as a whole, when the clients
attempt to reconnect (and then fail eventually and then
reconnect and so on).
Obviously, I am describing a specific system implementation,
which needs more built-in protections against this failure mode,
but solving the heartbeat problem would prevent that mode in the
first place :)
I'm eager to have this problem fixed and would be willing to
take a shot at it if someone could provide a bit of guidance.
The problem is easily reproducible in a pathological scenario
like this:
1. Create a database named "test"
2. Attach a filter to the database:
{
"language": "erlang",
"views": {
},
"filters": {
"test": "fun({Doc}, _) ->\n false end."
}
}
3. Open up a continuous feed using that filter.
curl
"localhost:5984/test/_changes?filter=test/test&feed=continuous&heartbeat=5000"
4. Write many docs into the database
(one of my test scripts)
#!/bin/sh
COUNTER=0
while [ $COUNTER -lt 3000 ]; do
ITS=0
while [ $ITS -lt 5 ]; do
PAYLOAD="{\"docType\":\"CS_MANIFEST\",
\"contentSetPath\":\"/some/path/${COUNTER}/${ITS}\",
\"versionName\":\"$COUNTER\", \"linkDate\":123456789${COUNTER}}"
curl -X POST -d "$PAYLOAD" -H
"Content-Type:application/json" http://localhost:5984/test
let ITS=ITS+1
done
let COUNTER=COUNTER+1
done
5. Notice the heartbeat stops until the script has completed
Matt
