[GitHub] couchdb pull request: 2114 Admin party not explained
Github user kxepal commented on the pull request: https://github.com/apache/couchdb/pull/158#issuecomment-36307618 Look good, but what would you say for the next variant: http://imgur.com/vSfMufe,oCxjJjg Note, that Admin Party button is red and attracts user's attention even if sidebar is collapsed. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Assigned] (COUCHDB-2129) Edit configuration option name
[ https://issues.apache.org/jira/browse/COUCHDB-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sue Lockwood reassigned COUCHDB-2129: - Assignee: Sue Lockwood > Edit configuration option name > -- > > Key: COUCHDB-2129 > URL: https://issues.apache.org/jira/browse/COUCHDB-2129 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Alexander Shorin >Assignee: Sue Lockwood > > Have you ever made a typo there? That's a doubtful feature since there is no > atomic operation for config option rename in CouchDB. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-2114) Admin party is not explained
[ https://issues.apache.org/jira/browse/COUCHDB-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915103#comment-13915103 ] Sue Lockwood commented on COUCHDB-2114: --- https://github.com/apache/couchdb/pull/158 > Admin party is not explained > > > Key: COUCHDB-2114 > URL: https://issues.apache.org/jira/browse/COUCHDB-2114 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Alexander Shorin >Assignee: Sue Lockwood > > Futon explain what is Admin Party and why you should fix it. Fauxton doesn't -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (COUCHDB-2128) Autocomplete section name
[ https://issues.apache.org/jira/browse/COUCHDB-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sue Lockwood reassigned COUCHDB-2128: - Assignee: Sue Lockwood > Autocomplete section name > - > > Key: COUCHDB-2128 > URL: https://issues.apache.org/jira/browse/COUCHDB-2128 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Alexander Shorin >Assignee: Sue Lockwood > > Common use case is addition of new options to the existed sections, not > creating new ones. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[GitHub] couchdb pull request: 2114 Admin party not explained
GitHub user deathbearbrown opened a pull request: https://github.com/apache/couchdb/pull/158 2114 Admin party not explained Added the "everyone is an admin" & "fix this" note and move the text around on the page. Got rid of the extra header You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/couchdb 2114-Admin-party-not-explained Alternatively you can review and apply these changes as the patch at: https://github.com/apache/couchdb/pull/158.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #158 commit 48f586f850a4cc92e938d84bfc98ba33f125861e Author: suelockwood Date: 2014-02-27T20:33:48Z Added the "everyone is an admin" & "fix this" note and move the text around on the page. Got rid of the extra header --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Assigned] (COUCHDB-2127) Config value edit button looks awkward and makes rows dance
[ https://issues.apache.org/jira/browse/COUCHDB-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sue Lockwood reassigned COUCHDB-2127: - Assignee: Sue Lockwood I have a Branch for this that I will PR when it gets to the mirror. I also fixed a lot of issues I found in the template here. The reusable template was using IDs instead of classes for selectors. :( I added the doubleclick edit. I fixed it so the table doesn't bounce around. > Config value edit button looks awkward and makes rows dance > --- > > Key: COUCHDB-2127 > URL: https://issues.apache.org/jira/browse/COUCHDB-2127 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Alexander Shorin >Assignee: Sue Lockwood > > Futon allows to edit values just by double click. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2177) Poor use of screen real-estate
Zachary Lym created COUCHDB-2177: Summary: Poor use of screen real-estate Key: COUCHDB-2177 URL: https://issues.apache.org/jira/browse/COUCHDB-2177 Project: CouchDB Issue Type: Brainstorming Security Level: public (Regular issues) Components: Fauxton Reporter: Zachary Lym Fauxton is a HUGE improvement on the UX for CouchDB. However, the editor uses, optimistically, 20% of the available screen-space effectively: !http://i.imgur.com/V4l63NR.gif! Obviously, this will be an ongoing task, but I would like to propose an adjustment in thinking about the map/reduce screen: we should focus on making map/reduce jobs not easier to edit but [learnable|http://worrydream.com/LearnableProgramming/]. I would suggest a live editing feature which pre-populates a small sample set of documents and updates interactively according to the map/reduce job (inspired by [debuggex's cool debugging interface | https://www.debuggex.com/] for regex queries). As a beginning, I would suggest basic syntax highlighting which corresponds to fields in the actual example documents. Eventually, this would lead to more complex highlighting of correlations between actions in the code editor and the docs themselves. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (COUCHDB-2126) Configuration page is broken
[ https://issues.apache.org/jira/browse/COUCHDB-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sue Lockwood reassigned COUCHDB-2126: - Assignee: Sue Lockwood Added a branch with this. Will submit PR when it's on the mirror. The collection just needed a comparitor to sort everything alphabetically > Configuration page is broken > > > Key: COUCHDB-2126 > URL: https://issues.apache.org/jira/browse/COUCHDB-2126 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Alexander Shorin >Assignee: Sue Lockwood > > Futon shows options sorted by section name / option name. Fauxton applies > some random order for them. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-2114) Admin party is not explained
[ https://issues.apache.org/jira/browse/COUCHDB-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915024#comment-13915024 ] Sue Lockwood commented on COUCHDB-2114: --- added a branch for this. will PR > Admin party is not explained > > > Key: COUCHDB-2114 > URL: https://issues.apache.org/jira/browse/COUCHDB-2114 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Alexander Shorin > > Futon explain what is Admin Party and why you should fix it. Fauxton doesn't -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (COUCHDB-2114) Admin party is not explained
[ https://issues.apache.org/jira/browse/COUCHDB-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sue Lockwood reassigned COUCHDB-2114: - Assignee: Sue Lockwood > Admin party is not explained > > > Key: COUCHDB-2114 > URL: https://issues.apache.org/jira/browse/COUCHDB-2114 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Alexander Shorin >Assignee: Sue Lockwood > > Futon explain what is Admin Party and why you should fix it. Fauxton doesn't -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-523) View API POST keys to retrieve multiple docs by key could also allow for multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... } params in the POST
[
https://issues.apache.org/jira/browse/COUCHDB-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914988#comment-13914988
]
ASF subversion and git services commented on COUCHDB-523:
-
Commit 3015c8554ae38fc3fa7890209c5e394e5995e1c8 in couchdb-couch-mrview's
branch refs/heads/1993-bigcouch-couch-mrview from [~chewbranca]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb-couch-mrview.git;h=3015c85 ]
Add support for multi query views
This adds support for making multiple view queries in one request by
supplying a "queries" list in a POST request body. The primary
implementation was ported over from chttpd_view:multi_query_view/5.
The support added here is two fold. First, we add multi_query_view
support to the single node interface in couch_mrview_http. Second we
add support in couch_mrview_http:view_cb/2 to allow chttpd to utilize
this callback as well.
This also switches updates the #vacc record from setting a multi_query
flag, to instead setting a should_close flag. Now
couch_mrview_http:view_cb/2 will only start a new delayed response if
#vacc.resp is undefined, and similarly, it will only close a delayed
response if #vacc.should_close is true.
COUCHDB-523
COUCHDB-1993
> View API POST keys to retrieve multiple docs by key could also allow for
> multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... }
> params in the POST
>
>
> Key: COUCHDB-523
> URL: https://issues.apache.org/jira/browse/COUCHDB-523
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Reporter: Nathan Stott
>Assignee: Russell Branca
>Priority: Minor
> Attachments: couch_httpd_view.erl, multi_start_end_key.diff,
> ranged_key_post.diff
>
>
> It would be useful if I could do a single POST to a view to retrieve multiple
> ranges specified by startkey, endkey.
> The format could be as follows:
> { "ranges": [ { "startkey": "a", "endkey": "c" }, { "startkey":"g",
> "endkey":"z" } ] }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-1993) Make fabric work with the refactored view engine
[ https://issues.apache.org/jira/browse/COUCHDB-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914989#comment-13914989 ] ASF subversion and git services commented on COUCHDB-1993: -- Commit 3015c8554ae38fc3fa7890209c5e394e5995e1c8 in couchdb-couch-mrview's branch refs/heads/1993-bigcouch-couch-mrview from [~chewbranca] [ https://git-wip-us.apache.org/repos/asf?p=couchdb-couch-mrview.git;h=3015c85 ] Add support for multi query views This adds support for making multiple view queries in one request by supplying a "queries" list in a POST request body. The primary implementation was ported over from chttpd_view:multi_query_view/5. The support added here is two fold. First, we add multi_query_view support to the single node interface in couch_mrview_http. Second we add support in couch_mrview_http:view_cb/2 to allow chttpd to utilize this callback as well. This also switches updates the #vacc record from setting a multi_query flag, to instead setting a should_close flag. Now couch_mrview_http:view_cb/2 will only start a new delayed response if #vacc.resp is undefined, and similarly, it will only close a delayed response if #vacc.should_close is true. COUCHDB-523 COUCHDB-1993 > Make fabric work with the refactored view engine > > > Key: COUCHDB-1993 > URL: https://issues.apache.org/jira/browse/COUCHDB-1993 > Project: CouchDB > Issue Type: Improvement > Components: BigCouch >Reporter: Volker Mische >Assignee: Russell Branca > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1993) Make fabric work with the refactored view engine
[ https://issues.apache.org/jira/browse/COUCHDB-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914987#comment-13914987 ] ASF subversion and git services commented on COUCHDB-1993: -- Commit b78d2e78cae88116bf89a3a16735e86ab5bea228 in couchdb-chttpd's branch refs/heads/1993-bigcouch-couch-mrview from [~chewbranca] [ https://git-wip-us.apache.org/repos/asf?p=couchdb-chttpd.git;h=b78d2e7 ] Update chttpd_view to use couch_mrview for multi query views This switches to using the couch_mrview implementation for handling multi query view requests, both for fetching the views through fabric and also the http callbacks. One concern I have with this implementation that needs to be tested, is whether calling couch_mrview_util:get_view in multi_query_view is appropriate. What happens when the database or the ddoc does not exist on the node handling this request? I think the ddoc should be fine as we load that from the ddoc_cache, but I'm less sure about the db. We need to make this request so we can perform the validations on the view, both for the url query params, and also for every set of additional params provided in the list of queries. COUCHDB-523 COUCHDB-1993 > Make fabric work with the refactored view engine > > > Key: COUCHDB-1993 > URL: https://issues.apache.org/jira/browse/COUCHDB-1993 > Project: CouchDB > Issue Type: Improvement > Components: BigCouch >Reporter: Volker Mische >Assignee: Russell Branca > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-523) View API POST keys to retrieve multiple docs by key could also allow for multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... } params in the POST
[
https://issues.apache.org/jira/browse/COUCHDB-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914986#comment-13914986
]
ASF subversion and git services commented on COUCHDB-523:
-
Commit b78d2e78cae88116bf89a3a16735e86ab5bea228 in couchdb-chttpd's branch
refs/heads/1993-bigcouch-couch-mrview from [~chewbranca]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb-chttpd.git;h=b78d2e7 ]
Update chttpd_view to use couch_mrview for multi query views
This switches to using the couch_mrview implementation for handling
multi query view requests, both for fetching the views through fabric
and also the http callbacks.
One concern I have with this implementation that needs to be tested,
is whether calling couch_mrview_util:get_view in multi_query_view is
appropriate. What happens when the database or the ddoc does not exist
on the node handling this request? I think the ddoc should be fine as
we load that from the ddoc_cache, but I'm less sure about the db. We
need to make this request so we can perform the validations on the
view, both for the url query params, and also for every set of
additional params provided in the list of queries.
COUCHDB-523
COUCHDB-1993
> View API POST keys to retrieve multiple docs by key could also allow for
> multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... }
> params in the POST
>
>
> Key: COUCHDB-523
> URL: https://issues.apache.org/jira/browse/COUCHDB-523
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Reporter: Nathan Stott
>Assignee: Russell Branca
>Priority: Minor
> Attachments: couch_httpd_view.erl, multi_start_end_key.diff,
> ranged_key_post.diff
>
>
> It would be useful if I could do a single POST to a view to retrieve multiple
> ranges specified by startkey, endkey.
> The format could be as follows:
> { "ranges": [ { "startkey": "a", "endkey": "c" }, { "startkey":"g",
> "endkey":"z" } ] }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-523) View API POST keys to retrieve multiple docs by key could also allow for multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... } params in the POST
[
https://issues.apache.org/jira/browse/COUCHDB-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914984#comment-13914984
]
ASF subversion and git services commented on COUCHDB-523:
-
Commit 017430dc393a7b36a83e0e8faa63b80859e4bc2f in couchdb-fabric's branch
refs/heads/1993-bigcouch-couch-mrview from [~chewbranca]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb-fabric.git;h=017430d ]
HACK: send a meta callback from fabric_view_reduce:handle_message/3
Hack alert. This sends a meta row from the handle_message callback in
fabric_view_reduce for the case of receiving a total_and_offset
messsage. Prior to couch_mrview, the view reduce implementation did
not send this message to fabric_view_reduce.
The hack is that we don't do the proper row collection worker dance
like we do in the handle_message callback for #view_row. I added a
temporary field to the #collector record to keep track of whether
we've sent the meta row yet to ensure it only gets sent once.
The primary motivation for this hack is that it provides a clean and
elegant solution to understanding when a view output stream is
starting. This is used to cleanup unecessary code in
couch_mrview_http:view_cb/2, and it's also essential for doing multi
query views through fabric.
I strongly feel sending the meta row is the right general approach,
but the devil is in the details as usual. To do this properly, we need
to funnel this through fabric_view:maybe_send_row, which gets awkward
in a hurry. So I've decided to temporarily introduce this hack to
solidify the API allowing the multi_query_view implementation to be
completed. Next step is to figure out how to fix this hack.
COUCHDB-523
COUCHDB-1993
> View API POST keys to retrieve multiple docs by key could also allow for
> multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... }
> params in the POST
>
>
> Key: COUCHDB-523
> URL: https://issues.apache.org/jira/browse/COUCHDB-523
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Reporter: Nathan Stott
>Assignee: Russell Branca
>Priority: Minor
> Attachments: couch_httpd_view.erl, multi_start_end_key.diff,
> ranged_key_post.diff
>
>
> It would be useful if I could do a single POST to a view to retrieve multiple
> ranges specified by startkey, endkey.
> The format could be as follows:
> { "ranges": [ { "startkey": "a", "endkey": "c" }, { "startkey":"g",
> "endkey":"z" } ] }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-1993) Make fabric work with the refactored view engine
[ https://issues.apache.org/jira/browse/COUCHDB-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914985#comment-13914985 ] ASF subversion and git services commented on COUCHDB-1993: -- Commit 017430dc393a7b36a83e0e8faa63b80859e4bc2f in couchdb-fabric's branch refs/heads/1993-bigcouch-couch-mrview from [~chewbranca] [ https://git-wip-us.apache.org/repos/asf?p=couchdb-fabric.git;h=017430d ] HACK: send a meta callback from fabric_view_reduce:handle_message/3 Hack alert. This sends a meta row from the handle_message callback in fabric_view_reduce for the case of receiving a total_and_offset messsage. Prior to couch_mrview, the view reduce implementation did not send this message to fabric_view_reduce. The hack is that we don't do the proper row collection worker dance like we do in the handle_message callback for #view_row. I added a temporary field to the #collector record to keep track of whether we've sent the meta row yet to ensure it only gets sent once. The primary motivation for this hack is that it provides a clean and elegant solution to understanding when a view output stream is starting. This is used to cleanup unecessary code in couch_mrview_http:view_cb/2, and it's also essential for doing multi query views through fabric. I strongly feel sending the meta row is the right general approach, but the devil is in the details as usual. To do this properly, we need to funnel this through fabric_view:maybe_send_row, which gets awkward in a hurry. So I've decided to temporarily introduce this hack to solidify the API allowing the multi_query_view implementation to be completed. Next step is to figure out how to fix this hack. COUCHDB-523 COUCHDB-1993 > Make fabric work with the refactored view engine > > > Key: COUCHDB-1993 > URL: https://issues.apache.org/jira/browse/COUCHDB-1993 > Project: CouchDB > Issue Type: Improvement > Components: BigCouch >Reporter: Volker Mische >Assignee: Russell Branca > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-2176) Map/Reduce views within views
[
https://issues.apache.org/jira/browse/COUCHDB-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914949#comment-13914949
]
Adam Kocoloski commented on COUCHDB-2176:
-
It's been discussed a number of times on the dev@ list dating all the way back
to 2009, but I'm not aware of any pre-existing JIRA ticket. It's a significant
effort; some good news is that the work [~benoitc] did on adding sequence
indexes to views is quite likely foundational for this feature.
> Map/Reduce views within views
> -
>
> Key: COUCHDB-2176
> URL: https://issues.apache.org/jira/browse/COUCHDB-2176
> Project: CouchDB
> Issue Type: Wish
> Security Level: public(Regular issues)
>Reporter: Nolan Lawson
>
> I don't know if this has already been discussed, but often with CouchDB I've
> run into a situation where a single map/reduce view couldn't quite slice my
> data in the way I needed.
> For instance, say you want to order rows by the _value_ of an emit function,
> rather than the key. E.g., you want to emit a certain key, reduce it using
> {{_count}}, and then order that output by the counts. Currently you'd have
> to stuff the output of the first view into another database (manually) and
> then create a new view on top of that one.
> It's also pretty common for apps to have different flavors of
> "detail/summary" views, each one optimized for a different page on the web
> site (e.g. "my inbox", "message summary", "message with details/attachments",
> "message thread", etc.). In the past I've simply resorted to redundancy,
> uploading the same data represented in different ways but all as documents in
> separate databases, but this is a pain to manage.
> Instead, I'd love it if the input of one view could simply be the output of
> another view. This would create endless flexibility and obviate the need for
> a lot of tinkering with the emit values (e.g. with linked documents). I'm
> not sure what the complexity would be of introducing this into the CouchDB
> code, but from a user's point of view it would definitely be nice to have.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
Re: [ANNOUNCE] Max Thayer elected as CouchDB committer
> >>> On 25 February 2014 12:20, Noah Slater wrote: > >>> > Dear community, > > I am pleased to announce that the CouchDB Project Management Committee > has elected Max Thayer as a CouchDB committer. > > Apache ID: garbados > > IRC nick: garbados > > Twitter: garbados > > By default, external contributions to the project follow the > Review-Then-Commit model. Being a committer means you can follow the > Commit-Then-Review model. In other words, Max can now make changes at > will. > > This election was made in recognition of Max's existing contributions > and commitment to the project. > > Please join me in extending a warm welcome to Max! > > On behalf of the CouchDB PMC, > > -- > Noah Slater > https://twitter.com/nslater > > >>> > >>> > >>> -- > >>> Andy Wenk > >>> Hamburg - Germany > >>> RockIt! > >>> > >>> http://www.couchdb-buch.de > >>> http://www.pg-praxisbuch.de > >>> > >>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 > >>> > >>> https://people.apache.org/keys/committer/andywenk.asc > >>> > > > > -- Dave Cottlehuber Sent from my PDP11
[jira] [Created] (COUCHDB-2176) Map/Reduce views within views
Nolan Lawson created COUCHDB-2176:
-
Summary: Map/Reduce views within views
Key: COUCHDB-2176
URL: https://issues.apache.org/jira/browse/COUCHDB-2176
Project: CouchDB
Issue Type: Wish
Security Level: public (Regular issues)
Reporter: Nolan Lawson
I don't know if this has already been discussed, but often with CouchDB I've
run into a situation where a single map/reduce view couldn't quite slice my
data in the way I needed.
For instance, say you want to order rows by the _value_ of an emit function,
rather than the key. E.g., you want to emit a certain key, reduce it using
{{_count}}, and then order that output by the counts. Currently you'd have to
stuff the output of the first view into another database (manually) and then
create a new view on top of that one.
It's also pretty common for apps to have different flavors of "detail/summary"
views, each one optimized for a different page on the web site (e.g. "my
inbox", "message summary", "message with details/attachments", "message
thread", etc"). In the past I've simply resorted to redundancy, uploading the
same data represented in different ways but all as documents in separate
databases, but this is a pain to manage.
Instead, I'd love it if the input of one view could simply be the output of
another view. This would create endless flexibility and obviate the need for a
lot of tinkering with the emit values (e.g. with linked documents). I'm not
sure what the complexity would be of introducing this into the CouchDB code,
but from a user's point of view it would definitely be nice to have.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (COUCHDB-2176) Map/Reduce views within views
[
https://issues.apache.org/jira/browse/COUCHDB-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nolan Lawson updated COUCHDB-2176:
--
Description:
I don't know if this has already been discussed, but often with CouchDB I've
run into a situation where a single map/reduce view couldn't quite slice my
data in the way I needed.
For instance, say you want to order rows by the _value_ of an emit function,
rather than the key. E.g., you want to emit a certain key, reduce it using
{{_count}}, and then order that output by the counts. Currently you'd have to
stuff the output of the first view into another database (manually) and then
create a new view on top of that one.
It's also pretty common for apps to have different flavors of "detail/summary"
views, each one optimized for a different page on the web site (e.g. "my
inbox", "message summary", "message with details/attachments", "message
thread", etc.). In the past I've simply resorted to redundancy, uploading the
same data represented in different ways but all as documents in separate
databases, but this is a pain to manage.
Instead, I'd love it if the input of one view could simply be the output of
another view. This would create endless flexibility and obviate the need for a
lot of tinkering with the emit values (e.g. with linked documents). I'm not
sure what the complexity would be of introducing this into the CouchDB code,
but from a user's point of view it would definitely be nice to have.
was:
I don't know if this has already been discussed, but often with CouchDB I've
run into a situation where a single map/reduce view couldn't quite slice my
data in the way I needed.
For instance, say you want to order rows by the _value_ of an emit function,
rather than the key. E.g., you want to emit a certain key, reduce it using
{{_count}}, and then order that output by the counts. Currently you'd have to
stuff the output of the first view into another database (manually) and then
create a new view on top of that one.
It's also pretty common for apps to have different flavors of "detail/summary"
views, each one optimized for a different page on the web site (e.g. "my
inbox", "message summary", "message with details/attachments", "message
thread", etc"). In the past I've simply resorted to redundancy, uploading the
same data represented in different ways but all as documents in separate
databases, but this is a pain to manage.
Instead, I'd love it if the input of one view could simply be the output of
another view. This would create endless flexibility and obviate the need for a
lot of tinkering with the emit values (e.g. with linked documents). I'm not
sure what the complexity would be of introducing this into the CouchDB code,
but from a user's point of view it would definitely be nice to have.
> Map/Reduce views within views
> -
>
> Key: COUCHDB-2176
> URL: https://issues.apache.org/jira/browse/COUCHDB-2176
> Project: CouchDB
> Issue Type: Wish
> Security Level: public(Regular issues)
>Reporter: Nolan Lawson
>
> I don't know if this has already been discussed, but often with CouchDB I've
> run into a situation where a single map/reduce view couldn't quite slice my
> data in the way I needed.
> For instance, say you want to order rows by the _value_ of an emit function,
> rather than the key. E.g., you want to emit a certain key, reduce it using
> {{_count}}, and then order that output by the counts. Currently you'd have
> to stuff the output of the first view into another database (manually) and
> then create a new view on top of that one.
> It's also pretty common for apps to have different flavors of
> "detail/summary" views, each one optimized for a different page on the web
> site (e.g. "my inbox", "message summary", "message with details/attachments",
> "message thread", etc.). In the past I've simply resorted to redundancy,
> uploading the same data represented in different ways but all as documents in
> separate databases, but this is a pain to manage.
> Instead, I'd love it if the input of one view could simply be the output of
> another view. This would create endless flexibility and obviate the need for
> a lot of tinkering with the emit values (e.g. with linked documents). I'm
> not sure what the complexity would be of introducing this into the CouchDB
> code, but from a user's point of view it would definitely be nice to have.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-2065) Overwrite a document with a single request
[
https://issues.apache.org/jira/browse/COUCHDB-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914905#comment-13914905
]
Robert Newson commented on COUCHDB-2065:
Thanks for letting us know. I agree that a really thorough exposition of *why*
couchdb does this would be great to have. We obviously have some text on this
from the book, the wiki and the docs, but not, I don't think, a single article
you could read that covers the entire thing in detail.
> Overwrite a document with a single request
> --
>
> Key: COUCHDB-2065
> URL: https://issues.apache.org/jira/browse/COUCHDB-2065
> Project: CouchDB
> Issue Type: New Feature
> Security Level: public(Regular issues)
>Reporter: Nolan Lawson
>
> It would be convenient to have the option to overwrite documents with a
> single request, rather than having to GET, check the _rev, POST/PUT, possibly
> deal with conflicts, and then continue POST/PUTing until success. It could
> be something as simple as:
> {code}
> PUT localhost:5984/mydb/mydoc?force=true
> {code}
> If two callers attempt to update the same document at the same time, whoever
> gets there last would win.
> Prompted by a [discussion in
> PouchDB|https://github.com/daleharvey/pouchdb/issues/1388].
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-2065) Overwrite a document with a single request
[
https://issues.apache.org/jira/browse/COUCHDB-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914880#comment-13914880
]
Nolan Lawson commented on COUCHDB-2065:
---
Hey Robert,
Thanks for the thoughtful responses. Largely based on the problems you
identified, we decided to abandon this idea in PouchDB as well.
Modularization would be cool, but I think in the meantime the only solution is
good documentation to help guide users towards the most robust implementation.
Luckily the Couch docs themselves are great for that!
> Overwrite a document with a single request
> --
>
> Key: COUCHDB-2065
> URL: https://issues.apache.org/jira/browse/COUCHDB-2065
> Project: CouchDB
> Issue Type: New Feature
> Security Level: public(Regular issues)
>Reporter: Nolan Lawson
>
> It would be convenient to have the option to overwrite documents with a
> single request, rather than having to GET, check the _rev, POST/PUT, possibly
> deal with conflicts, and then continue POST/PUTing until success. It could
> be something as simple as:
> {code}
> PUT localhost:5984/mydb/mydoc?force=true
> {code}
> If two callers attempt to update the same document at the same time, whoever
> gets there last would win.
> Prompted by a [discussion in
> PouchDB|https://github.com/daleharvey/pouchdb/issues/1388].
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
Re: [ANNOUNCE] Benjamin Young elected as CouchDB committer
Welcome Ben! Great to have you on board. Cheers Garren On 25 Feb 2014, at 8:19 PM, Russell Branca wrote: > Congrats Ben! > > > -Russell > > > On Tue, Feb 25, 2014 at 7:19 AM, Benoit Chesneau wrote: > >> On Tue, Feb 25, 2014 at 3:12 PM, Benjamin Young >> wrote: >>> >>> On 2/25/14, 7:37 AM, Dave Cottlehuber wrote: >> >> On 25 February 2014 09:53, Robert Samuel Newson wrote: >> >>> Dear community, >>> >>> I am pleased to announce that the CouchDB Project Management >> Committee >>> has >>> elected Benjamin Young as a CouchDB committer. >>> >>> Apache ID: bigbluehat >>> >>> IRC nick: bigbluehat >>> >>> Twitter: bigbluehat congratulations Ben! IIRC you were one of the first people I met wrt to CouchDB back at Couch Camp 2010! >>> >>> Yeah. We were roommates. :) >>> >>> Good memories. >>> >>> +1 to another one of those "wifi-from-the-trees" events. :D >> >> welcome on board :) - benoit >>
Re: [ANNOUNCE] Max Thayer elected as CouchDB committer
Welcome Max! Great to have you one board. Cheers Garren On 25 Feb 2014, at 9:24 PM, Benjamin Young wrote: > Welcome, Max! > > On 2/25/14, 1:29 PM, Russell Branca wrote: >> Welcome Max! >> >> >> -Russell >> >> >> On Tue, Feb 25, 2014 at 3:33 AM, Andy Wenk wrote: >> >>> Hi Max - welcome to the club :) >>> >>> Cheers >>> >>> Andy >>> >>> >>> On 25 February 2014 12:20, Noah Slater wrote: >>> Dear community, I am pleased to announce that the CouchDB Project Management Committee has elected Max Thayer as a CouchDB committer. Apache ID: garbados IRC nick: garbados Twitter: garbados By default, external contributions to the project follow the Review-Then-Commit model. Being a committer means you can follow the Commit-Then-Review model. In other words, Max can now make changes at will. This election was made in recognition of Max's existing contributions and commitment to the project. Please join me in extending a warm welcome to Max! On behalf of the CouchDB PMC, -- Noah Slater https://twitter.com/nslater >>> >>> >>> -- >>> Andy Wenk >>> Hamburg - Germany >>> RockIt! >>> >>> http://www.couchdb-buch.de >>> http://www.pg-praxisbuch.de >>> >>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 >>> >>> https://people.apache.org/keys/committer/andywenk.asc >>> >
[jira] [Commented] (COUCHDB-1986) 04-replication-large-atts.t times out
[ https://issues.apache.org/jira/browse/COUCHDB-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914640#comment-13914640 ] Andy Wenk commented on COUCHDB-1986: I added the recbuf patch in 1.6.x. The patch is to change -define(RECBUF_SIZE, 8192). to -define(RECBUF_SIZE, 8192 * 4). in src/mochiweb/internal.hrl. The result for make check is: /Users/andwen/project/couchdb/couchdb-src-clean-1-6/src/couch_replicator/test/04-replication-large-atts.t ... 531/? Bailout called. Further testing stopped: Timeout waiting for replication to finish FAILED--Further testing stopped: Timeout waiting for replication to finish make[2]: *** [check] Error 127 make[1]: *** [check-recursive] Error 1 make: *** [check-recursive] Error 1 then changed the recbuf patch to src/mochiweb/internal.hrl: -define(RECBUF_SIZE, 8192 * 8). And all test successfull. R16B03-1 (erts-5.10.4), Mac OS X 10.9.2, 16 GB 1600 MHz DDR3, 2.8 GHz Intel Core i7, APPLE SSD SM0512F Media 500MB > 04-replication-large-atts.t times out > - > > Key: COUCHDB-1986 > URL: https://issues.apache.org/jira/browse/COUCHDB-1986 > Project: CouchDB > Issue Type: Bug > Components: Replication >Affects Versions: 1.5.0 >Reporter: Jan Lehnardt > > 04-replication-large-atts.t gets stuck around 558, sometimes a little earlier > or later, but it times out eventually, regardless of the timeout. I tried > doubling and such. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2175) Metadata isn't available for new ddocs
Alexander Shorin created COUCHDB-2175: - Summary: Metadata isn't available for new ddocs Key: COUCHDB-2175 URL: https://issues.apache.org/jira/browse/COUCHDB-2175 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2174) Improve design documents metadata
Alexander Shorin created COUCHDB-2174: - Summary: Improve design documents metadata Key: COUCHDB-2174 URL: https://issues.apache.org/jira/browse/COUCHDB-2174 Project: CouchDB Issue Type: Improvement Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin Currently fields are organized in random way. Some grouping would be helpful. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2173) Better error handling on database security page
Alexander Shorin created COUCHDB-2173:
-
Summary: Better error handling on database security page
Key: COUCHDB-2173
URL: https://issues.apache.org/jira/browse/COUCHDB-2173
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: Fauxton
Reporter: Alexander Shorin
If user has no permissions to change database security, on first attempt to add
some user/role to it Fauxton shows the popup:
{quote}
{"error":"unauthorized","reason":"You are not a db or server admin."}
{quote}
but on second attempt to add the same name no error showed and it seems that
value just silently ignored.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (COUCHDB-2172) Show popup instead on redirecting to noAccess page
Alexander Shorin created COUCHDB-2172: - Summary: Show popup instead on redirecting to noAccess page Key: COUCHDB-2172 URL: https://issues.apache.org/jira/browse/COUCHDB-2172 Project: CouchDB Issue Type: Improvement Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin This really annoys to get redirected just to read that you don't have access to some resource. Fauxton could provide more nicer popup message that user has no permission to access to some resource and keep him on the place where he currently is. If he comes by direct URL to such resource - yes, redirection to noAccess page is reasonable. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2171) noAccess page makes no difference between 401 and 403 responses
Alexander Shorin created COUCHDB-2171:
-
Summary: noAccess page makes no difference between 401 and 403
responses
Key: COUCHDB-2171
URL: https://issues.apache.org/jira/browse/COUCHDB-2171
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: Fauxton
Reporter: Alexander Shorin
This page says:
{quote}
Access Denied
You do not have permission to view this page.
You might need to login to view this page
{quote}
even if you're already logged in. So actually, you might not need to login
"again" and this suggestion to solve the issue is useless.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (COUCHDB-2168) Highlight the line in editor where JSON is broken
Alexander Shorin created COUCHDB-2168: - Summary: Highlight the line in editor where JSON is broken Key: COUCHDB-2168 URL: https://issues.apache.org/jira/browse/COUCHDB-2168 Project: CouchDB Issue Type: Improvement Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin Subj. extremely useful for large documents. Suggestions about how to fix the issue are also welcome. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2170) Weird error if anonymous user will try to create new admin
Alexander Shorin created COUCHDB-2170:
-
Summary: Weird error if anonymous user will try to create new admin
Key: COUCHDB-2170
URL: https://issues.apache.org/jira/browse/COUCHDB-2170
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: Fauxton
Reporter: Alexander Shorin
When admin party is fixed and anonymous user trying to create new admin he'll
get the next error: {{Could not create admin. Reason[object Object].}}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (COUCHDB-2169) There is no way back from noAccess page
Alexander Shorin created COUCHDB-2169: - Summary: There is no way back from noAccess page Key: COUCHDB-2169 URL: https://issues.apache.org/jira/browse/COUCHDB-2169 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin If you somehow get on noAccess page, you couldn't click on Back button since in browser history the previous url is that one which redirected you on noAccess page. So actually you're trapped inside and have to navigate to prev-prev page in history. Also it would be awesome if noAccess page will provide url to way back without using browser history. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2167) Compare documents
Alexander Shorin created COUCHDB-2167: - Summary: Compare documents Key: COUCHDB-2167 URL: https://issues.apache.org/jira/browse/COUCHDB-2167 Project: CouchDB Issue Type: New Feature Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin Compare two documents producing readable diff and provide json patch for download. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2166) Rename duplicate document to "copy ..." or "clone ..."
Alexander Shorin created COUCHDB-2166: - Summary: Rename duplicate document to "copy ..." or "clone ..." Key: COUCHDB-2166 URL: https://issues.apache.org/jira/browse/COUCHDB-2166 Project: CouchDB Issue Type: Improvement Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin Since actually you creates new document, not a duplicate for existed one (_id and _rev are different, there could be two different documents with same _id in the same database). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2165) Back link to database view from document one sets limit=100
Alexander Shorin created COUCHDB-2165: - Summary: Back link to database view from document one sets limit=100 Key: COUCHDB-2165 URL: https://issues.apache.org/jira/browse/COUCHDB-2165 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin By default Fauxton applies limit=20 for showing view results. But when you navigate to the document's page and click on Database name on page header Fauxton will apply limit=100 for pagination. This could be dangerous if include_docs is set as true. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2164) Attachments with slashes in name escaped incorrectly
Alexander Shorin created COUCHDB-2164: - Summary: Attachments with slashes in name escaped incorrectly Key: COUCHDB-2164 URL: https://issues.apache.org/jira/browse/COUCHDB-2164 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin Attachment name: /foo/bar/baz URL in Futon: http://localhost:5984/test/doc/%2ffoo%2fbar%2fbaz URL in Fauxton: http://localhost:5984/test/doc//foo/bar/baz -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2163) Visualize document revision tree and navigate between these revisions
Alexander Shorin created COUCHDB-2163: - Summary: Visualize document revision tree and navigate between these revisions Key: COUCHDB-2163 URL: https://issues.apache.org/jira/browse/COUCHDB-2163 Project: CouchDB Issue Type: New Feature Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin Futon allows just to navigate between revisions on the same branch. It would be awesome if Fauxton will visualize revision tree like [visualizeRevTree|https://github.com/neojski/visualizeRevTree] does and allows to jump to the specific revision in single click. Currently Fauxton only shows the "latest" document's revision with no "history" navigation. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2162) Better color theme for JSON editor
Alexander Shorin created COUCHDB-2162: - Summary: Better color theme for JSON editor Key: COUCHDB-2162 URL: https://issues.apache.org/jira/browse/COUCHDB-2162 Project: CouchDB Issue Type: Improvement Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin Current theme is quite awkward. It's very highlights booleans by orange color, but almost makes no difference between other types. Probably some dark theme where every type would have own recognizable color would improve readability of JSON data and fit more dark-red Fauxton design. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2160) Fields-view for documents
Alexander Shorin created COUCHDB-2160: - Summary: Fields-view for documents Key: COUCHDB-2160 URL: https://issues.apache.org/jira/browse/COUCHDB-2160 Project: CouchDB Issue Type: New Feature Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin Futon provides two representation of documents: raw JSON and, how I called it, fields-view where document is represented in nicer k-v table form. This representation is very user friendly, since you don't have to care about JSON syntax - you don't even have to know about it. You just double clicks on value, enters something and Futon guesses right type for the input. No commas, no quotes, no brackets, just keys and values. Currently, Fauxton has no such view providing documents representation only as raw JSON (thought it has very rich editor for it). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2161) Easy access to attachments
Alexander Shorin created COUCHDB-2161: - Summary: Easy access to attachments Key: COUCHDB-2161 URL: https://issues.apache.org/jira/browse/COUCHDB-2161 Project: CouchDB Issue Type: Improvement Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin Futon allows this in single click from document view. Fauxton - in two clicks. Is it possible to improve editors for providing references on other resources? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1986) 04-replication-large-atts.t times out
[ https://issues.apache.org/jira/browse/COUCHDB-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914534#comment-13914534 ] Andy Wenk commented on COUCHDB-1986: [~benoitc] Erlang R16B03-1 (erts-5.10.4) > 04-replication-large-atts.t times out > - > > Key: COUCHDB-1986 > URL: https://issues.apache.org/jira/browse/COUCHDB-1986 > Project: CouchDB > Issue Type: Bug > Components: Replication >Affects Versions: 1.5.0 >Reporter: Jan Lehnardt > > 04-replication-large-atts.t gets stuck around 558, sometimes a little earlier > or later, but it times out eventually, regardless of the timeout. I tried > doubling and such. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1986) 04-replication-large-atts.t times out
[ https://issues.apache.org/jira/browse/COUCHDB-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914531#comment-13914531 ] Alexander Shorin commented on COUCHDB-1986: --- [~andywenk] timeout without recbuf patch or with it? > 04-replication-large-atts.t times out > - > > Key: COUCHDB-1986 > URL: https://issues.apache.org/jira/browse/COUCHDB-1986 > Project: CouchDB > Issue Type: Bug > Components: Replication >Affects Versions: 1.5.0 >Reporter: Jan Lehnardt > > 04-replication-large-atts.t gets stuck around 558, sometimes a little earlier > or later, but it times out eventually, regardless of the timeout. I tried > doubling and such. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1986) 04-replication-large-atts.t times out
[ https://issues.apache.org/jira/browse/COUCHDB-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914511#comment-13914511 ] Benoit Chesneau commented on COUCHDB-1986: -- Odd, I can confirm that all etst spass here. Also on travis-ci: https://travis-ci.org/refuge/rcouch It's looks like disk related issue or something. Also what is your erlang version? > 04-replication-large-atts.t times out > - > > Key: COUCHDB-1986 > URL: https://issues.apache.org/jira/browse/COUCHDB-1986 > Project: CouchDB > Issue Type: Bug > Components: Replication >Affects Versions: 1.5.0 >Reporter: Jan Lehnardt > > 04-replication-large-atts.t gets stuck around 558, sometimes a little earlier > or later, but it times out eventually, regardless of the timeout. I tried > doubling and such. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1986) 04-replication-large-atts.t times out
[
https://issues.apache.org/jira/browse/COUCHDB-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914506#comment-13914506
]
Andy Wenk commented on COUCHDB-1986:
[~kxepal] result for 1.6 make check:
Users/andwen/project/couchdb/couchdb-src-clean/src/couch_replicator/test/04-replication-large-atts.t
... 477/? Bailout called. Further testing stopped: Timeout waiting for
replication to finish
FAILED--Further testing stopped: Timeout waiting for replication to finish
make[2]: *** [check] Error 127
make[1]: *** [check-recursive] Error 1
make: *** [check-recursive] Error 1
[~benoitc] make test -> all erlang tests pass.
make check:
erlang_views.js ... fail
javascript traceback:
FAIL
Reason: The database could not be created, the file already exists.
Trace back (most recent call first):
508:
/Users/andwen/project/couchdb/couchdb-src-clean/test/etap/../../test/out/share/www/script/couch.js
CouchError([object Object])
471:
/Users/andwen/project/couchdb/couchdb-src-clean/test/etap/../../test/out/share/www/script/couch.js
([object CouchHTTP])
33:
/Users/andwen/project/couchdb/couchdb-src-clean/test/etap/../../test/out/share/www/script/couch.js
()
100:
/Users/andwen/project/couchdb/couchdb-src-clean/test/etap/../../test/out/share/www/script/test/erlang_views.js
()
378:
/Users/andwen/project/couchdb/couchdb-src-clean/test/etap/../../test/out/share/www/script/couch_test_runner.js
run_on_modified_server([object Array],(function () {var doc = {_id: "1
25:
/Users/andwen/project/couchdb/couchdb-src-clean/test/etap/../../test/out/share/www/script/test/erlang_views.js
()
36:
/Users/andwen/project/couchdb/couchdb-src-clean/test/etap/../../test/javascript/cli_runner.js
runTest()
47:
/Users/andwen/project/couchdb/couchdb-src-clean/test/etap/../../test/javascript/cli_runner.js
view_pagination.js ... ok
view_sandboxing.js ... ok
view_update_seq.js ... ok
1/87 tests failed
make: *** [testjs] Error 1
I guess this is just because the db already exists?
> 04-replication-large-atts.t times out
> -
>
> Key: COUCHDB-1986
> URL: https://issues.apache.org/jira/browse/COUCHDB-1986
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.5.0
>Reporter: Jan Lehnardt
>
> 04-replication-large-atts.t gets stuck around 558, sometimes a little earlier
> or later, but it times out eventually, regardless of the timeout. I tried
> doubling and such.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-1986) 04-replication-large-atts.t times out
[ https://issues.apache.org/jira/browse/COUCHDB-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914371#comment-13914371 ] Benoit Chesneau commented on COUCHDB-1986: -- [~andywenk] can you by chance try on the 1994-merge-rcouch branch? I don't reproduce the error anymore here, but it may be just my machines... > 04-replication-large-atts.t times out > - > > Key: COUCHDB-1986 > URL: https://issues.apache.org/jira/browse/COUCHDB-1986 > Project: CouchDB > Issue Type: Bug > Components: Replication >Affects Versions: 1.5.0 >Reporter: Jan Lehnardt > > 04-replication-large-atts.t gets stuck around 558, sometimes a little earlier > or later, but it times out eventually, regardless of the timeout. I tried > doubling and such. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1986) 04-replication-large-atts.t times out
[ https://issues.apache.org/jira/browse/COUCHDB-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914358#comment-13914358 ] Andy Wenk commented on COUCHDB-1986: [~janl] same problem: Test Summary Report --- ./test/etap/200-view-group-no-db-leaks.t(Wstat: 0 Tests: 28 Failed: 2) Failed tests: 5, 9 Files=51, Tests=1214, 253 wallclock secs ( 0.54 usr 0.11 sys + 83.10 cusr 23.09 csys = 106.84 CPU) Result: FAIL make: *** [check] Error 1 > 04-replication-large-atts.t times out > - > > Key: COUCHDB-1986 > URL: https://issues.apache.org/jira/browse/COUCHDB-1986 > Project: CouchDB > Issue Type: Bug > Components: Replication >Affects Versions: 1.5.0 >Reporter: Jan Lehnardt > > 04-replication-large-atts.t gets stuck around 558, sometimes a little earlier > or later, but it times out eventually, regardless of the timeout. I tried > doubling and such. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1986) 04-replication-large-atts.t times out
[ https://issues.apache.org/jira/browse/COUCHDB-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914208#comment-13914208 ] Andy Wenk commented on COUCHDB-1986: [~kxepal] remotes/origin/1.6.x ? [~janl] will do and report > 04-replication-large-atts.t times out > - > > Key: COUCHDB-1986 > URL: https://issues.apache.org/jira/browse/COUCHDB-1986 > Project: CouchDB > Issue Type: Bug > Components: Replication >Affects Versions: 1.5.0 >Reporter: Jan Lehnardt > > 04-replication-large-atts.t gets stuck around 558, sometimes a little earlier > or later, but it times out eventually, regardless of the timeout. I tried > doubling and such. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-2104) Configuration files added to the local.d folder on windows is not read
[ https://issues.apache.org/jira/browse/COUCHDB-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914199#comment-13914199 ] Ole Johan commented on COUCHDB-2104: I am running a script that changes two lines in the configuration before CouchDB startup, and it seems like a better solution to just append and change configuration in one external file (in case of configuration corruption caused by the script). I have solved this now by putting all config in default.ini (CouchDB will never be updated automatically), and having the wanted two lines in local.ini. A change in the documentation that states that the wanted action is only possible on Unix-systems will be okay > Configuration files added to the local.d folder on windows is not read > -- > > Key: COUCHDB-2104 > URL: https://issues.apache.org/jira/browse/COUCHDB-2104 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: Database Core >Affects Versions: 1.5.0 >Reporter: Ole Johan >Priority: Minor > > It works if I am using the same files in the local.d folder on ubuntu, but on > Windows the configuration is never read. > I am using the information provided here: > http://docs.couchdb.org/en/latest/config/intro.html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
