[jira] [Commented] (COUCHDB-3076) CouchDB 2.0 Blog Series: Feature: replicator
[ https://issues.apache.org/jira/browse/COUCHDB-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419612#comment-15419612 ] Nick Vatamaniuc commented on COUCHDB-3076: -- Good idea, Jenn. I added a little line about me at the end. Also linked to the syntax of Mango selectors Jan suggested. Let me know if anything else needs to be one. > CouchDB 2.0 Blog Series: Feature: replicator > > > Key: COUCHDB-3076 > URL: https://issues.apache.org/jira/browse/COUCHDB-3076 > Project: CouchDB > Issue Type: New JIRA Project >Reporter: Jenn Turner >Assignee: kzx >Priority: Minor > > This issue is to track progress on a series of blog posts promoting the > release of CouchDB 2.0. > Topic: Feature: replicator > -TBD > Nick Vatamaniuc volunteered via email thread: > https://lists.apache.org/thread.html/47637fe64739d26eca81a109650022b77c92aac05d15d49b18ade813@%3Cdev.couchdb.apache.org%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-3101) Builtin reduce functions should not throw errors
[
https://issues.apache.org/jira/browse/COUCHDB-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419316#comment-15419316
]
Joan Touzet commented on COUCHDB-3101:
--
One more +1 for {{null}} for the reasons stated above.
> Builtin reduce functions should not throw errors
>
>
> Key: COUCHDB-3101
> URL: https://issues.apache.org/jira/browse/COUCHDB-3101
> Project: CouchDB
> Issue Type: Bug
> Components: View Server Support
>Reporter: Paul Joseph Davis
>
> So I just figured out we have an issue with the builtin reduce functions.
> Currently, if they receive invalid data they'll throw an error. Unfortunately
> what ends up happening is that if the error is never corrected then the view
> files end up becoming bloated and refusing to open (because they're searching
> for a header as Jay pointed out the other week).
> We should either return null or ignore the bad data. My preference would be
> to return null so that it indicates bad data was given somewhere but I could
> also see just dropping the bad value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COUCHDB-3101) Builtin reduce functions should not throw errors
[
https://issues.apache.org/jira/browse/COUCHDB-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419039#comment-15419039
]
Nick Vatamaniuc commented on COUCHDB-3101:
--
I think it makes sense to signal user about the error somehow. So I like
returning null better.
There is already a pattern of returning an error to user if their reduce
function doesn't reduce fast enough:
{code}query_server_config.reduce_limit{code} And that is enabled by default.
(Also, there is currently a bug in it how it calculates the limit with a pr
fix: https://github.com/apache/couchdb/pull/425 ).
> Builtin reduce functions should not throw errors
>
>
> Key: COUCHDB-3101
> URL: https://issues.apache.org/jira/browse/COUCHDB-3101
> Project: CouchDB
> Issue Type: Bug
> Components: View Server Support
>Reporter: Paul Joseph Davis
>
> So I just figured out we have an issue with the builtin reduce functions.
> Currently, if they receive invalid data they'll throw an error. Unfortunately
> what ends up happening is that if the error is never corrected then the view
> files end up becoming bloated and refusing to open (because they're searching
> for a header as Jay pointed out the other week).
> We should either return null or ignore the bad data. My preference would be
> to return null so that it indicates bad data was given somewhere but I could
> also see just dropping the bad value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-3102) The xxx_config_listener doesn't restart after a failure
ILYA created COUCHDB-3102:
-
Summary: The xxx_config_listener doesn't restart after a failure
Key: COUCHDB-3102
URL: https://issues.apache.org/jira/browse/COUCHDB-3102
Project: CouchDB
Issue Type: Bug
Reporter: ILYA
The
[config_listener_mon|https://github.com/apache/couchdb-config/blob/master/src/config_listener_mon.erl#L44]
monitors the caller.
However in lots of places we use [following
pattern|https://github.com/apache/couchdb-chttpd/blob/master/src/chttpd_config_listener.erl#L45:L49]
{code}
handle_config_terminate(_Server, _Reason, State) ->
spawn(fun() ->
timer:sleep(5000),
config:listen_for_changes(?MODULE, State)
end).
{code}
In this case the spawned fun exits right after the monitor has been established.
Which means config_listener_mon would terminate. Effectively removing event
handler from config_event process (gen_event event manager).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COUCHDB-3101) Builtin reduce functions should not throw errors
[ https://issues.apache.org/jira/browse/COUCHDB-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419015#comment-15419015 ] Jay Doane commented on COUCHDB-3101: FWIW, I definitely think giving the end user an indication that they supplied a bad value is the better approach. +1 for null. > Builtin reduce functions should not throw errors > > > Key: COUCHDB-3101 > URL: https://issues.apache.org/jira/browse/COUCHDB-3101 > Project: CouchDB > Issue Type: Bug > Components: View Server Support >Reporter: Paul Joseph Davis > > So I just figured out we have an issue with the builtin reduce functions. > Currently, if they receive invalid data they'll throw an error. Unfortunately > what ends up happening is that if the error is never corrected then the view > files end up becoming bloated and refusing to open (because they're searching > for a header as Jay pointed out the other week). > We should either return null or ignore the bad data. My preference would be > to return null so that it indicates bad data was given somewhere but I could > also see just dropping the bad value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-3101) Builtin reduce functions should not throw errors
[ https://issues.apache.org/jira/browse/COUCHDB-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15418998#comment-15418998 ] Paul Joseph Davis commented on COUCHDB-3101: I should note, I prefer null because if we drop data the user doesn't realize was malformed then they'll have no signal that something is broken and may instead rely on probably invalid data out of the reducer. Also notice the null is just for any reducer that's broken it doesn't null out any other reducer or anything of that nature. So basically if say a user has a _sum reduce function and emits a string as a value this would return null for any reduce query for that specific view. Any other view in the same ddoc would be unaffected. > Builtin reduce functions should not throw errors > > > Key: COUCHDB-3101 > URL: https://issues.apache.org/jira/browse/COUCHDB-3101 > Project: CouchDB > Issue Type: Bug > Components: View Server Support >Reporter: Paul Joseph Davis > > So I just figured out we have an issue with the builtin reduce functions. > Currently, if they receive invalid data they'll throw an error. Unfortunately > what ends up happening is that if the error is never corrected then the view > files end up becoming bloated and refusing to open (because they're searching > for a header as Jay pointed out the other week). > We should either return null or ignore the bad data. My preference would be > to return null so that it indicates bad data was given somewhere but I could > also see just dropping the bad value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-3101) Builtin reduce functions should not throw errors
Paul Joseph Davis created COUCHDB-3101: -- Summary: Builtin reduce functions should not throw errors Key: COUCHDB-3101 URL: https://issues.apache.org/jira/browse/COUCHDB-3101 Project: CouchDB Issue Type: Bug Components: View Server Support Reporter: Paul Joseph Davis So I just figured out we have an issue with the builtin reduce functions. Currently, if they receive invalid data they'll throw an error. Unfortunately what ends up happening is that if the error is never corrected then the view files end up becoming bloated and refusing to open (because they're searching for a header as Jay pointed out the other week). We should either return null or ignore the bad data. My preference would be to return null so that it indicates bad data was given somewhere but I could also see just dropping the bad value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COUCHDB-3100) require_valid_user is not working
[ https://issues.apache.org/jira/browse/COUCHDB-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tiago Pereira closed COUCHDB-3100. -- Resolution: Not A Bug > require_valid_user is not working > - > > Key: COUCHDB-3100 > URL: https://issues.apache.org/jira/browse/COUCHDB-3100 > Project: CouchDB > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Tiago Pereira > > When the configuration "require_valid_user = true" is added to the local.ini, > the server ignores it and the database is still kept public. This problem was > replicated in klaemo's docker image 2.0-single and 2.0-rc3 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] couchdb-fauxton pull request #739: Breadcrumbs React port: remove jump-to-db
Github user robertkowalski closed the pull request at: https://github.com/apache/couchdb-fauxton/pull/739 --- 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. ---
[GitHub] couchdb-fauxton issue #739: Breadcrumbs React port: remove jump-to-db
Github user robertkowalski commented on the issue: https://github.com/apache/couchdb-fauxton/pull/739 merged! one step more towards 100% react! --- 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] [Reopened] (COUCHDB-3100) require_valid_user is not working
[ https://issues.apache.org/jira/browse/COUCHDB-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin reopened COUCHDB-3100: --- I think it's not not a bug, but still a bug either in user expectations or lack chttpd option to require valid user. 5986 is a backdoor port that should not be available for public. > require_valid_user is not working > - > > Key: COUCHDB-3100 > URL: https://issues.apache.org/jira/browse/COUCHDB-3100 > Project: CouchDB > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Tiago Pereira > > When the configuration "require_valid_user = true" is added to the local.ini, > the server ignores it and the database is still kept public. This problem was > replicated in klaemo's docker image 2.0-single and 2.0-rc3 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-3100) require_valid_user is not working
[ https://issues.apache.org/jira/browse/COUCHDB-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15418931#comment-15418931 ] Tiago Pereira commented on COUCHDB-3100: Actually, disregard this issue. In my configuration, I was using port 5984 which was the chttpd port. I was applying all my permissions on [couch_httpd_auth], which was running on port 5986. Changing my local.ini to ``` [chttpd] bind_address = 127.0.0.1 port = 5984 [httpd] bind_address = 0.0.0.0 port = 5986 [couchdb] uuid = myuuid [admins] root = mypassword [couch_httpd_auth] require_valid_user = true secret = mysecret ``` And pointing to port 5986 resolved the issue. > require_valid_user is not working > - > > Key: COUCHDB-3100 > URL: https://issues.apache.org/jira/browse/COUCHDB-3100 > Project: CouchDB > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Tiago Pereira > > When the configuration "require_valid_user = true" is added to the local.ini, > the server ignores it and the database is still kept public. This problem was > replicated in klaemo's docker image 2.0-single and 2.0-rc3 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] couchdb-fauxton pull request #753: react port: use react-select for database...
Github user robertkowalski commented on a diff in the pull request:
https://github.com/apache/couchdb-fauxton/pull/753#discussion_r74586359
--- Diff: app/addons/databases/stores.js ---
@@ -72,13 +72,19 @@ var DatabasesStore = FauxtonAPI.Store.extend({
},
getDatabaseNames: function () {
-if (this._backboneCollection) {
- return _.map(this._backboneCollection.toJSON(), function (item, key)
{
-return item.name;
- });
-} else {
+if (!this._backboneCollection || !this._backboneCollection.length) {
--- End diff --
yes!
---
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.
---
[GitHub] couchdb-fauxton pull request #753: react port: use react-select for database...
Github user robertkowalski closed the pull request at: https://github.com/apache/couchdb-fauxton/pull/753 --- 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] [Commented] (COUCHDB-3100) require_valid_user is not working
[ https://issues.apache.org/jira/browse/COUCHDB-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15418707#comment-15418707 ] Tiago Pereira commented on COUCHDB-3100: Just noticed this might be the same as #COUCHDB-3098 > require_valid_user is not working > - > > Key: COUCHDB-3100 > URL: https://issues.apache.org/jira/browse/COUCHDB-3100 > Project: CouchDB > Issue Type: Bug >Reporter: Tiago Pereira > > When the configuration "require_valid_user = true" is added to the local.ini, > the server ignores it and the database is still kept public. This problem was > replicated in klaemo's docker image 2.0-single and 2.0-rc3 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-3100) require_valid_user is not working
Tiago Pereira created COUCHDB-3100: -- Summary: require_valid_user is not working Key: COUCHDB-3100 URL: https://issues.apache.org/jira/browse/COUCHDB-3100 Project: CouchDB Issue Type: Bug Reporter: Tiago Pereira When the configuration "require_valid_user = true" is added to the local.ini, the server ignores it and the database is still kept public. This problem was replicated in klaemo's docker image 2.0-single and 2.0-rc3 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] couchdb-fauxton issue #750: Config section reactjs rewrite
Github user robertkowalski commented on the issue: https://github.com/apache/couchdb-fauxton/pull/750 very good work! thank you! --- 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. ---
[GitHub] couchdb-fauxton pull request #750: Config section reactjs rewrite
Github user robertkowalski commented on a diff in the pull request:
https://github.com/apache/couchdb-fauxton/pull/750#discussion_r74572056
--- Diff: tasks/helper.js ---
@@ -14,7 +14,7 @@ var fs = require('fs'),
path = require('path');
exports.devServerPort = 8000;
-exports.couch = 'http://localhost:5984/';
+exports.couch = 'http://couch:5984/';
--- End diff --
pls fix to http://127.0.0.1:5984
---
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.
---
[GitHub] couchdb-fauxton pull request #750: Config section reactjs rewrite
Github user robertkowalski commented on a diff in the pull request:
https://github.com/apache/couchdb-fauxton/pull/750#discussion_r74572031
--- Diff: devserver.js ---
@@ -18,7 +18,7 @@ var loadSettings = function () {
port: process.env.FAUXTON_PORT || 8000,
contentSecurityPolicy: true,
proxy: {
- target: 'http://127.0.0.1:5984',
+ target: 'http://couch:5984',
--- End diff --
pls fix back to http://127.0.0.1:5984
---
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.
---
[GitHub] couchdb-fauxton pull request #750: Config section reactjs rewrite
Github user robertkowalski commented on a diff in the pull request:
https://github.com/apache/couchdb-fauxton/pull/750#discussion_r74571961
--- Diff: devserver.js ---
@@ -1,4 +1,4 @@
-var spawn = require('child_process').spawn;
+var spawn = require('cross-spawn').spawn;
--- End diff --
no need for cross-spawn, i think the minimum version of node to run fauxton
is 4
---
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.
---
[GitHub] couchdb-fauxton pull request #750: Config section reactjs rewrite
Github user robertkowalski commented on a diff in the pull request:
https://github.com/apache/couchdb-fauxton/pull/750#discussion_r74571323
--- Diff: app/addons/config/components.react.jsx ---
@@ -0,0 +1,398 @@
+// Licensed under the Apache License, Version 2.0 (the "License"); you
may not
+// use this file except in compliance with the License. You may obtain a
copy of
+// the License at
+//
+//http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT
+// WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See
the
+// License for the specific language governing permissions and
limitations under
+// the License.
+
+import React from "react";
+import ReactDOM from "react-dom";
+import Stores from "./stores";
+import Actions from "./actions";
+import {Overlay, Button, Popover} from "react-bootstrap";
+import Components from "../components/react-components.react";
+import FauxtonComponents from "../fauxton/components.react";
+
+const configStore = Stores.configStore;
+
+var ConfigTableController = React.createClass({
+ getStoreState () {
+return {
+ options: configStore.getOptions(),
+ loading: configStore.isLoading()
+};
+ },
+
+ getInitialState () {
+return this.getStoreState();
+ },
+
+ componentDidMount () {
+configStore.on('change', this.onChange, this);
+ },
+
+ componentWillUnmount () {
+configStore.off('change', this.onChange, this);
--- End diff --
no binding needed for unregistering:
```
configStore.off('change', this.onChange);
```
---
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.
---
[GitHub] couchdb-fauxton pull request #750: Config section reactjs rewrite
Github user robertkowalski commented on a diff in the pull request:
https://github.com/apache/couchdb-fauxton/pull/750#discussion_r74571039
--- Diff: app/addons/config/assets/less/config.less ---
@@ -9,31 +9,55 @@
// WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See
the
// License for the specific language governing permissions and
limitations under
// the License.
-//
+
@import "../../../../../assets/less/variables.less";
@import "../../../../../assets/less/bootstrap/mixins.less";
-
-
.config-item {
height: 65px;
- .js-value-input {
+ .config-value-form {
+button {
+ margin-left: 8px;
+}
+ }
+
+ .config-value-input {
width: 80%;
margin: 0;
}
- .js-show-value,
- .js-delete-value {
+
+ .config-show-value,
+ .config-delete-value {
cursor: pointer;
}
- .js-hidden {
-display: none;
- }
+
.text-center {
text-align: center;
}
button { width: 7%;}
+
+ transition: background-color 100ms;
+}
+
+.config-item:hover {
+ background-color: #e0e0e0;
+}
+
+.table-striped tbody > tr.config-item:nth-child(odd) > td,
+.table-striped tbody > tr.config-item:nth-child(odd) > th {
+ transition: background-color 100ms;
+}
+
+.table-striped tbody > tr.config-item:nth-child(odd):hover > td,
+.table-striped tbody > tr.config-item:nth-child(odd):hover > th {
+ background-color: #e7e7e7;
+}
--- End diff --
this changes the color for all striped tables in fauxton - is that the
intention?
---
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.
---
