[jira] [Commented] (COUCHDB-1060) CouchDB should use a secure password hash method instead of the current one
[ https://issues.apache.org/jira/browse/COUCHDB-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031452#comment-13031452 ] Chris Anderson commented on COUCHDB-1060: - The current implementation avoids a special server side API for creating documents in the _users database. Architecturally, I am fine with a special API for the user's database -- however it may make sense to keep it in the "shape" of the CouchDB API. So for instance creating a user would go through an _update function, which could compute the salt and hash, before storing in the _users db. The alternative would be to define a custom endpoint for POST requests to create documents in the user db, and then we'd have to bike-shed and document that API. However if someone wants to write all that code, I won't stop you. If energy is going to poured in here, the other thing we should consider is a "write-only" database mode, so that users can PUT and POST, but not GET. In this case the _update function would still be a good way to do the salt and hashing. Anyway, this is a distinct topic but related. > CouchDB should use a secure password hash method instead of the current one > --- > > Key: COUCHDB-1060 > URL: https://issues.apache.org/jira/browse/COUCHDB-1060 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Affects Versions: 1.0.2 >Reporter: Nuutti Kotivuori >Assignee: Robert Newson >Priority: Minor > Fix For: 1.2 > > Attachments: pbkdf2.erl, pbkdf2.erl > > > CouchDB passwords are stored in a salted, hashed format of a 128-bit salt > combined with the password under SHA-1. This method thwarts rainbow table > attacks, but is utterly ineffective against any dictionary attacks as > computing SHA-1 is very fast indeed. > If passwords are to be stored in a non-plaintext equivalent format, the hash > function needs to be a "slow" hash function. Suitable candidates for this > could be bcrypt, scrypt and PBKDF2. Of the choices, only PBKDF2 is really > widely used, standardized and goverment approved. (Note: don't be fooled that > the PBKDF2 is a "key derivation" function - in this case, it is exactly the > same thing as a slow password hash.) > http://en.wikipedia.org/wiki/PBKDF2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1060) CouchDB should use a secure password hash method instead of the current one
[ https://issues.apache.org/jira/browse/COUCHDB-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030450#comment-13030450 ] Chris Anderson commented on COUCHDB-1060: - I love this. Currently the user passwords are too insecure. A slow hash algorithm makes offline cracking harder. It would require changes to the API to have crypto only run on the server, but it might be simpler. Chris > CouchDB should use a secure password hash method instead of the current one > --- > > Key: COUCHDB-1060 > URL: https://issues.apache.org/jira/browse/COUCHDB-1060 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Affects Versions: 1.0.2 >Reporter: Nuutti Kotivuori >Assignee: Robert Newson >Priority: Minor > Fix For: 1.2 > > Attachments: pbkdf2.erl, pbkdf2.erl > > > CouchDB passwords are stored in a salted, hashed format of a 128-bit salt > combined with the password under SHA-1. This method thwarts rainbow table > attacks, but is utterly ineffective against any dictionary attacks as > computing SHA-1 is very fast indeed. > If passwords are to be stored in a non-plaintext equivalent format, the hash > function needs to be a "slow" hash function. Suitable candidates for this > could be bcrypt, scrypt and PBKDF2. Of the choices, only PBKDF2 is really > widely used, standardized and goverment approved. (Note: don't be fooled that > the PBKDF2 is a "key derivation" function - in this case, it is exactly the > same thing as a slow password hash.) > http://en.wikipedia.org/wiki/PBKDF2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1141) Docs deleted via PUT or POST do not have contents removed.
[ https://issues.apache.org/jira/browse/COUCHDB-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025586#comment-13025586 ] Chris Anderson commented on COUCHDB-1141: - This is proper behavior. (Or -- what Damien said...) The intent is to allow users the option to save audit data like deleted_at and deleted_by when they set _deleted=true. To read these documents you have to fetch them with their rev num. Now, I haven't figured out how to find their rev num except via the changes feed, and THAT might be an improvement we should make. > Docs deleted via PUT or POST do not have contents removed. > -- > > Key: COUCHDB-1141 > URL: https://issues.apache.org/jira/browse/COUCHDB-1141 > Project: CouchDB > Issue Type: Bug > Components: Database Core > Environment: All >Reporter: Wendall Cada >Assignee: Damien Katz > Fix For: 1.2 > > > If a doc is deleted via -X DELETE, the resulting doc contains only > id/rev_deleted:true. However, if a doc is deleted via PUT or POST, through > adding _deleted:true, the entire contents of the doc remains stored. Even > after compaction, the original document contents remain. > This issue is causing databases with large docs to become bloated over time, > as the original doc contents remain in the database even after being deleted. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COUCHDB-1092) Storing documents bodies as raw JSON binaries instead of serialized JSON terms
[
https://issues.apache.org/jira/browse/COUCHDB-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007913#comment-13007913
]
Chris Anderson commented on COUCHDB-1092:
-
Wowsers Filipe, this is great work!
Smaller database files are probably one of the biggest concerns out users have
(even more so than performance) so shrinking them *and* getting better
performance is a double win.
I am not concerned by the abstraction leakage evident in pattern matching on
binary bytes like "{" or "}" -- I might be if the leakage was not encapsulated,
and all over the code base, but with Filipe's patch, the chances that it will
lead to bugs because someone forgot to do something looks really really small.
I'd been generally against the idea of this optimization, because I
(mistakenly) thought it'd be a big gnarly patch that touches the whole
codebase. Kudos to Filipe for making it so focussed (and fast!).
I'd like to see it in trunk, I can't see any reason not to do so, since it
changes no behavior, is localized, and offers tangible benefits across the
board.
Chris
> Storing documents bodies as raw JSON binaries instead of serialized JSON terms
> --
>
> Key: COUCHDB-1092
> URL: https://issues.apache.org/jira/browse/COUCHDB-1092
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core
>Reporter: Filipe Manana
>Assignee: Filipe Manana
>
> Currently we store documents as Erlang serialized (via the term_to_binary/1
> BIF) EJSON.
> The proposed patch changes the database file format so that instead of
> storing serialized
> EJSON document bodies, it stores raw JSON binaries.
> The github branch is at:
> https://github.com/fdmanana/couchdb/tree/raw_json_docs
> Advantages:
> * what we write to disk is much smaller - a raw JSON binary can easily get up
> to 50% smaller
> (at least according to the tests I did)
> * when serving documents to a client we no longer need to JSON encode the
> document body
> read from the disk - this applies to individual document requests, view
> queries with
> ?include_docs=true, pull and push replications, and possibly other use
> cases.
> We just grab its body and prepend the _id, _rev and all the necessary
> metadata fields
> (this is via simple Erlang binary operations)
> * we avoid the EJSON term copying between request handlers and the db updater
> processes,
> between the work queues and the view updater process, between replicator
> processes, etc
> * before sending a document to the JavaScript view server, we no longer need
> to convert it
> from EJSON to JSON
> The changes done to the document write workflow are minimalist - after JSON
> decoding the
> document's JSON into EJSON and removing the metadata top level fields (_id,
> _rev, etc), it
> JSON encodes the resulting EJSON body into a binary - this consumes CPU of
> course but it
> brings 2 advantages:
> 1) we avoid the EJSON copy between the request process and the database
> updater process -
>for any realistic document size (4kb or more) this can be very expensive,
> specially
>when there are many nested structures (lists inside objects inside lists,
> etc)
> 2) before writing anything to the file, we do a term_to_binary([Len, Md5,
> TheThingToWrite])
>and then write the result to the file. A term_to_binary call with a binary
> as the input
>is very fast compared to a term_to_binary call with EJSON as input (or
> some other nested
>structure)
> I think both compensate the JSON encoding after the separation of meta data
> fields and non-meta data fields.
> The following relaximation graph, for documents with sizes of 4Kb, shows a
> significant
> performance increase both for writes and reads - especially reads.
> http://graphs.mikeal.couchone.com/#/graph/698bf36b6c64dbd19aa2bef63400b94f
> I've also made a few tests to see how much the improvement is when querying a
> view, for the
> first time, without ?stale=ok. The size difference of the databases (after
> compaction) is
> also very significant - this change can reduce the size at least 50% in
> common cases.
> The test databases were created in an instance built from that experimental
> branch.
> Then they were replicated into a CouchDB instance built from the current
> trunk.
> At the end both databases were compacted (to fairly compare their final
> sizes).
> The databases contain the following view:
> {
> "_id": "_design/test",
> "language": "javascript",
> "views": {
> "simple": {
> "map": "function(doc) { emit(doc.float1, doc.strings[1]); }"
> }
> }
> }
> ## Database with 500 000 docs of 2.5Kb each
> Document template is at:
> https://github.com/fdmanana/couchdb/blob/raw_json_docs/doc_2
[jira] Commented: (COUCHDB-1086) Improve config file write-back behavior.
[ https://issues.apache.org/jira/browse/COUCHDB-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004949#comment-13004949 ] Chris Anderson commented on COUCHDB-1086: - I think we should do what we can to make plugins smooth. Maybe we could have a COUCH_PLUGIN_INIS environment variable that is inserted between default.ini and local.ini > Improve config file write-back behavior. > - > > Key: COUCHDB-1086 > URL: https://issues.apache.org/jira/browse/COUCHDB-1086 > Project: CouchDB > Issue Type: Improvement > Components: Futon > Environment: Ubuntu 10.04 >Reporter: Michael Wiederhold >Priority: Minor > > 1) I install couchdb and change the bind address in default.ini to 0.0.0.0 so > I can access couch remotely. > 2) In futon I change the bind address to 127.0.0.1 and then refresh the web > page an the web ui disappears. > 3) I go back into the config file default.ini and the bind address is still > 0.0.0.0. > 4) I then go into local.ini and there is nothing except for comments. > 5) I restart the server and it binds to 127.0.0.1 and I cannot see futon. > The issue is that when changing the bind address in futon, futon puts the new > address in the config file with the highest priority which is in this case > the geocouch config file, but the proper place to put the new bind address is > in local.ini. > I marked this as critical because I can see it affecting a decent amount of > users. Should be a quick fix. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[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=12928833#action_12928833 ] Chris Anderson commented on COUCHDB-912: reviewing the patch. looks good except that config should not be read in an http responder. instead it should be read in the gen-server init and added to the httpd record or something so it's available in the responder. This is a little bit more performant, here's an example of where config is loaded. https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_httpd.erl#L76 > 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] Assigned: (COUCHDB-856) reduce_builtin fails
[
https://issues.apache.org/jira/browse/COUCHDB-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson reassigned COUCHDB-856:
--
Assignee: Chris Anderson
> reduce_builtin fails
>
>
> Key: COUCHDB-856
> URL: https://issues.apache.org/jira/browse/COUCHDB-856
> Project: CouchDB
> Issue Type: Bug
> Components: Test Suite
>Affects Versions: 1.0.1
> Environment: CentOS 5.5
>Reporter: Daniel Lockard
>Assignee: Chris Anderson
>
> reduce_builtin fails in the Futon test suite, with this error:
> {"message":"JSON.parse","fileName":"http://10.3.0.20:5984/_utils/script/couch.js?0.11.0","lineNumber":165,"stack":";(\"(function
> (doc) {emit(doc.integer, doc.integer);emit(doc.integer,
> doc.integer);})\",\"_stats\")@http://10.3.0.20:5984/_utils/script/couch.js?0.11.0:165\u000a((void
>
> 0))@http://10.3.0.20:5984/_utils/script/couch_test_runner.js?0.11.0:54\u000arun(0)@http://10.3.0.20:5984/_utils/script/couch_test_runner.js?0.11.0:84\u000a"}
> i get this dump in the logs
> http://pastebin.com/gSfZyXt8
> Or:
> [error] [<0.144.0>] ** Generic server <0.144.0> terminating
> ** Last message in was {'EXIT',<0.148.0>,
>{undef,
>[{erlang,min,[1,1]},
> {couch_query_servers,
> '-builtin_stats/2-fun-0-',2},
> {lists,foldl,3},
> {couch_query_servers,builtin_stats,2},
> {couch_query_servers,builtin_reduce,4},
> {couch_query_servers,reduce,3},
> {couch_view_group,'-init_group/4-fun-0-',4},
> {couch_btree,'-write_node/3-lc$^0/1-0-',3}]}}
> ** When Server state == {group_state,undefined,<<"test_suite_db">>,
> {"/usr/local/var/lib/couchdb",<<"test_suite_db">>,
> {group,
><<3,83,134,243,145,137,46,176,194,211,132,124,106,
> 32,233,59>>,
>{db,<0.118.0>,<0.119.0>,nil,
> <<"1282061287074150">>,<0.116.0>,<0.120.0>,
> {db_header,5,0,0,nil,nil,nil,0,nil,nil,1000},
> 0,
> {btree,<0.116.0>,
> {67650,{500,0}},
> #Fun,
> #Fun,
> #Fun,
> #Fun},
> {btree,<0.116.0>,
> {97633,500},
> #Fun,
> #Fun,
> #Fun,
> #Fun},
> {btree,<0.116.0>,nil,
> #Fun,
> #Fun,
> #Fun,nil},
> 500,<<"test_suite_db">>,
> "/usr/local/var/lib/couchdb/test_suite_db.couch",
> [],[],nil,
> {user_ctx,null,[],undefined},
> #Ref<0.0.0.1416>,1000,
> [before_header,after_header,on_file_open],
> false},
>nil,<<"_temp">>,<<"javascript">>,[],
>[{view,0,
> [<<"_temp">>],
> <<"(function (doc) {emit(doc.integer,
> doc.integer);emit(doc.integer, doc.integer);})">>,
> nil,
> [{<<"_temp">>,<<"_stats">>}],
> []}],
>nil,0,0,nil,nil}},
> {group,
>
> <<3,83,134,243,145,137,46,176,194,211,132,124,106,32,
> 233,59>>,
> {db,<0.118.0>,<0.119.0>,nil,<<"1282061287074150">>,
><0.116.0>,<0.120.0>,
>{db_header,5,0,0,nil,nil,nil,0,nil,nil,1000},
>0,
>{btree,<0.116.0>,
> {67650,{500,0}},
> #Fun,
> #Fun,
> #Fun,
> #Fun},
>{btree,<0.116.0>,
> {97633,500},
> #Fun,
> #Fun,
> #Fun,
> #Fun},
>{btree,<0.116.0>,nil,#Fun,
> #Fun,
>
[jira] Commented: (COUCHDB-891) Allow ?keys=["a","b"] for GET to _view and _list
[
https://issues.apache.org/jira/browse/COUCHDB-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917051#action_12917051
]
Chris Anderson commented on COUCHDB-891:
I think this would also be a good intro patch for someone new to the codebase.
> Allow ?keys=["a","b"] for GET to _view and _list
>
>
> Key: COUCHDB-891
> URL: https://issues.apache.org/jira/browse/COUCHDB-891
> Project: CouchDB
> Issue Type: New Feature
> Components: HTTP Interface
>Affects Versions: 1.0.1
> Environment: -
>Reporter: Michael Fellinger
>Priority: Minor
> Fix For: 1.0.2
>
>
> The idea was already described back in 2008 when the POST
> {"keys":["key1","key2"]} API was introduced.
> http://mail-archives.apache.org/mod_mbox/couchdb-dev/200811.mbox/%3c4910d88a.8000...@kore-nordmann.de%3e
> I'm looking at the source right now, but can't figure out how to implement
> this at the moment, and I'd love this to be part of CouchDB proper.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-886) Add option to set query options, defined in rewrites.json, as default
[
https://issues.apache.org/jira/browse/COUCHDB-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12909362#action_12909362
]
Chris Anderson commented on COUCHDB-886:
yes/
query >> request params >> defaults --> used requests
> Add option to set query options, defined in rewrites.json, as default
> -
>
> Key: COUCHDB-886
> URL: https://issues.apache.org/jira/browse/COUCHDB-886
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Reporter: Henrik Skupin
>
> With the latest version of CouchDB the URL parameters are not taken into
> account when the rewrites.json file specifies the same ones for the
> appropriate entry. See the following example:
> {
> "from" : "/general/reports",
> "to" : "_list/general_reports/general_reportsByDate",
> "query" : {
> "descending" : true,
> "limit" : 51
> }
> }
> default values: http://mozmill.hskupin.info/general/reports
> custom values: http://mozmill.hskupin.info/general/reports?limit=10
> Whether which URL you are loading, the values from rewrites.json are always
> used. Once the limit entry gets removed from that file, the URL parameter is
> used and 10 rows are displayed.
> As proposed by Benoit query entries should be explicitly allowed to have a
> default value. Otherwise the value from rewrites.json has the priority.
> "query": {
> "key": { "value": ":var", "default": 1}
> }
> Can true be used instead of a number? It could be confusing this way,
> especially when the value is also a number.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-886) Add option to set query options, defined in rewrites.json, as default
[
https://issues.apache.org/jira/browse/COUCHDB-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908938#action_12908938
]
Chris Anderson commented on COUCHDB-886:
Ryan's proposal is what I was proposing:
the required-query stuff overrides any defaults (if both specify a param)
I'm not sure about naming, I just want it to be clear to users which is which...
so "defaults" and "query" (maybe 'defaults' is better than 'default' as
'default' is a javascript keyword, which can be a surprise if you use it
unquoted)
or
"query" and "enforced-query"
or something else.
The only requirement being that one of them is named "query" for the sake of
backwards compatibility.
> Add option to set query options, defined in rewrites.json, as default
> -
>
> Key: COUCHDB-886
> URL: https://issues.apache.org/jira/browse/COUCHDB-886
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Reporter: Henrik Skupin
>
> With the latest version of CouchDB the URL parameters are not taken into
> account when the rewrites.json file specifies the same ones for the
> appropriate entry. See the following example:
> {
> "from" : "/general/reports",
> "to" : "_list/general_reports/general_reportsByDate",
> "query" : {
> "descending" : true,
> "limit" : 51
> }
> }
> default values: http://mozmill.hskupin.info/general/reports
> custom values: http://mozmill.hskupin.info/general/reports?limit=10
> Whether which URL you are loading, the values from rewrites.json are always
> used. Once the limit entry gets removed from that file, the URL parameter is
> used and 10 rows are displayed.
> As proposed by Benoit query entries should be explicitly allowed to have a
> default value. Otherwise the value from rewrites.json has the priority.
> "query": {
> "key": { "value": ":var", "default": 1}
> }
> Can true be used instead of a number? It could be confusing this way,
> especially when the value is also a number.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-886) Add option to set query options, defined in rewrites.json, as default
[
https://issues.apache.org/jira/browse/COUCHDB-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908620#action_12908620
]
Chris Anderson commented on COUCHDB-886:
I believe came to the conclusion that the feature would look like:
{
"from" : "/general/reports",
"to" : "_list/general_reports/general_reportsByDate",
"query" : {
"descending" : true
} ,
"default" : {
"limit: 51
}
}
where the "query" definition will continue to be mandatory, but the defaults
will be overridable by the client.
I'm not sure I like this... what if instead, the "query" parameter were to
revert to the old behavior (where the client can override it, and for the case
where application designers want to force a particular query, we could have
"enforced-query". with that notion, the previous example would look like this:
{
"from" : "/general/reports",
"to" : "_list/general_reports/general_reportsByDate",
"query" : {
"limit: 51
} ,
"enforced-query" : {
"descending" : true
}
}
The reason to have 2 members is to maintain backwards compatibility with
existing rewrite rules. I also think it is a bit clearer than the alternative.
> Add option to set query options, defined in rewrites.json, as default
> -
>
> Key: COUCHDB-886
> URL: https://issues.apache.org/jira/browse/COUCHDB-886
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Reporter: Henrik Skupin
>
> With the latest version of CouchDB the URL parameters are not taken into
> account when the rewrites.json file specifies the same ones for the
> appropriate entry. See the following example:
> {
> "from" : "/general/reports",
> "to" : "_list/general_reports/general_reportsByDate",
> "query" : {
> "descending" : true,
> "limit" : 51
> }
> }
> default values: http://mozmill.hskupin.info/general/reports
> custom values: http://mozmill.hskupin.info/general/reports?limit=10
> Whether which URL you are loading, the values from rewrites.json are always
> used. Once the limit entry gets removed from that file, the URL parameter is
> used and 10 rows are displayed.
> As proposed by Benoit query entries should be explicitly allowed to have a
> default value. Otherwise the value from rewrites.json has the priority.
> "query": {
> "key": { "value": ":var", "default": 1}
> }
> Can true be used instead of a number? It could be confusing this way,
> especially when the value is also a number.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-869) commonjs implementation creates circular references in the design document
[ https://issues.apache.org/jira/browse/COUCHDB-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908431#action_12908431 ] J Chris Anderson commented on COUCHDB-869: -- I just had a beautiful baby girl named Irma, so I don't plan to respond to mail, except occasionally if it's a fun one. If you have an urgent request, please CC he...@couch.io and we'll make sure someone reads it. Thanks, Chris PS. Please let me know if this responder is hitting mailing lists, that would be lame. -- Chris Anderson http://jchrisa.net -- couch.io > commonjs implementation creates circular references in the design document > -- > > Key: COUCHDB-869 > URL: https://issues.apache.org/jira/browse/COUCHDB-869 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Reporter: Chris Anderson > Fix For: 1.0.2 > > Attachments: commonjs_circular_ref.diff > > > this prevents JSON.stringify(this) from working in show functions, as the > JSON.stringify function gets too much recursion. The culprit is the parent > references created by our CommonJS implementation. > test attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COUCHDB-869) commonjs implementation creates circular references in the design document
[ https://issues.apache.org/jira/browse/COUCHDB-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson resolved COUCHDB-869. Resolution: Fixed fixed in r996266 and r996267 > commonjs implementation creates circular references in the design document > -- > > Key: COUCHDB-869 > URL: https://issues.apache.org/jira/browse/COUCHDB-869 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Reporter: Chris Anderson > Fix For: 1.0.2 > > Attachments: commonjs_circular_ref.diff > > > this prevents JSON.stringify(this) from working in show functions, as the > JSON.stringify function gets too much recursion. The culprit is the parent > references created by our CommonJS implementation. > test attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-869) commonjs implementation creates circular references in the design document
[ https://issues.apache.org/jira/browse/COUCHDB-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J Chris Anderson updated COUCHDB-869: - Comment: was deleted (was: I just had a beautiful baby girl named Irma, so I don't plan to respond to mail, except occasionally if it's a fun one. If you have an urgent request, please CC he...@couch.io and we'll make sure someone reads it. Thanks, Chris PS. Please let me know if this responder is hitting mailing lists, that would be lame. -- Chris Anderson http://jchrisa.net -- couch.io ) > commonjs implementation creates circular references in the design document > -- > > Key: COUCHDB-869 > URL: https://issues.apache.org/jira/browse/COUCHDB-869 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Reporter: Chris Anderson > Fix For: 1.0.2 > > Attachments: commonjs_circular_ref.diff > > > this prevents JSON.stringify(this) from working in show functions, as the > JSON.stringify function gets too much recursion. The culprit is the parent > references created by our CommonJS implementation. > test attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-869) commonjs implementation creates circular references in the design document
[ https://issues.apache.org/jira/browse/COUCHDB-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901926#action_12901926 ] J Chris Anderson commented on COUCHDB-869: -- I just had a beautiful baby girl named Irma, so I don't plan to respond to mail, except occasionally if it's a fun one. If you have an urgent request, please CC he...@couch.io and we'll make sure someone reads it. Thanks, Chris PS. Please let me know if this responder is hitting mailing lists, that would be lame. -- Chris Anderson http://jchrisa.net -- couch.io > commonjs implementation creates circular references in the design document > -- > > Key: COUCHDB-869 > URL: https://issues.apache.org/jira/browse/COUCHDB-869 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Reporter: Chris Anderson > Fix For: 1.0.2 > > Attachments: commonjs_circular_ref.diff > > > this prevents JSON.stringify(this) from working in show functions, as the > JSON.stringify function gets too much recursion. The culprit is the parent > references created by our CommonJS implementation. > test attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-869) commonjs implementation creates circular references in the design document
[ https://issues.apache.org/jira/browse/COUCHDB-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson updated COUCHDB-869: --- Attachment: commonjs_circular_ref.diff test case for design doc circular references > commonjs implementation creates circular references in the design document > -- > > Key: COUCHDB-869 > URL: https://issues.apache.org/jira/browse/COUCHDB-869 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Reporter: Chris Anderson > Fix For: 1.0.2 > > Attachments: commonjs_circular_ref.diff > > > this prevents JSON.stringify(this) from working in show functions, as the > JSON.stringify function gets too much recursion. The culprit is the parent > references created by our CommonJS implementation. > test attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-869) commonjs implementation creates circular references in the design document
commonjs implementation creates circular references in the design document -- Key: COUCHDB-869 URL: https://issues.apache.org/jira/browse/COUCHDB-869 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Reporter: Chris Anderson Fix For: 1.0.2 Attachments: commonjs_circular_ref.diff this prevents JSON.stringify(this) from working in show functions, as the JSON.stringify function gets too much recursion. The culprit is the parent references created by our CommonJS implementation. test attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-230) Add Support for Rewritable URL
[ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900814#action_12900814 ] Chris Anderson commented on COUCHDB-230: I'm am starting to get concerned about this feature (and the $foo pattern matching vhosts stuff as well) mostly because I'm not sure I understand all the implications of it. In the past when features have been proposed that have been complex enough to not be easy to reason about, we've decided against them. I'm not saying that's what we need to do hear, but I think that until we are totally clear about what we are and aren't getting into with this stuff, we should proceed with caution. > Add Support for Rewritable URL > -- > > Key: COUCHDB-230 > URL: https://issues.apache.org/jira/browse/COUCHDB-230 > Project: CouchDB > Issue Type: New Feature >Reporter: Patrick Aljord > Fix For: 1.0.2 > > Attachments: 0001-manage-aliases.patch > > > It would be good if couchdb would allow to rewrite urls so that instead of > having to write that: > http://127.0.0.1:5984/blogdb/_design/sofa/account.html > I could just write: > http://127.0.0.1:5984/blogdb/account > It could be done with the web server but having the rewritten rules in the db > would make it a bit easier for replication so we don't have to write the > rules on each web server where a db gets replicated. > Here are a few propositions from davisp: > alisdair: how so? rewriting urls should be in _design documents, > since they're in _design docs they should be limited to per db namespaces > bobesponja: I don't know that anyone has looked at it seriously, but > my first guess is that we'd just make a _design/doc "urls" member that's a > list of regex's and targets as is fairly standard practice > bobesponja: or perhaps, regex's -> erlang handler > the second might not be as fun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-230) Add Support for Rewritable URL
[ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899948#action_12899948 ] Chris Anderson commented on COUCHDB-230: not worrying about stomping on database names (Eg by allowing admins to vhost */foo = /foo/_design/foo/_rewrite ) I think is OK. I'm not sure about the $stuff, if only because that adds an entire new level of complexity to the implementation. one thing I like about the implementation now is how simple it is. > Add Support for Rewritable URL > -- > > Key: COUCHDB-230 > URL: https://issues.apache.org/jira/browse/COUCHDB-230 > Project: CouchDB > Issue Type: New Feature >Reporter: Patrick Aljord > Fix For: 1.0.2 > > > It would be good if couchdb would allow to rewrite urls so that instead of > having to write that: > http://127.0.0.1:5984/blogdb/_design/sofa/account.html > I could just write: > http://127.0.0.1:5984/blogdb/account > It could be done with the web server but having the rewritten rules in the db > would make it a bit easier for replication so we don't have to write the > rules on each web server where a db gets replicated. > Here are a few propositions from davisp: > alisdair: how so? rewriting urls should be in _design documents, > since they're in _design docs they should be limited to per db namespaces > bobesponja: I don't know that anyone has looked at it seriously, but > my first guess is that we'd just make a _design/doc "urls" member that's a > list of regex's and targets as is fairly standard practice > bobesponja: or perhaps, regex's -> erlang handler > the second might not be as fun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-230) Add Support for Rewritable URL
[ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899656#action_12899656 ] Chris Anderson commented on COUCHDB-230: I was thinking we could just extend the current vhosts api so that: [vhosts] example.com/foobar = /foo/_design/bar/_rewrite it would be up to the admin to avoid stomping on existing database names. I am more than happy to allow them to live with that risk. > Add Support for Rewritable URL > -- > > Key: COUCHDB-230 > URL: https://issues.apache.org/jira/browse/COUCHDB-230 > Project: CouchDB > Issue Type: New Feature >Reporter: Patrick Aljord > Fix For: 1.0.2 > > > It would be good if couchdb would allow to rewrite urls so that instead of > having to write that: > http://127.0.0.1:5984/blogdb/_design/sofa/account.html > I could just write: > http://127.0.0.1:5984/blogdb/account > It could be done with the web server but having the rewritten rules in the db > would make it a bit easier for replication so we don't have to write the > rules on each web server where a db gets replicated. > Here are a few propositions from davisp: > alisdair: how so? rewriting urls should be in _design documents, > since they're in _design docs they should be limited to per db namespaces > bobesponja: I don't know that anyone has looked at it seriously, but > my first guess is that we'd just make a _design/doc "urls" member that's a > list of regex's and targets as is fairly standard practice > bobesponja: or perhaps, regex's -> erlang handler > the second might not be as fun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-855) New host manager
[
https://issues.apache.org/jira/browse/COUCHDB-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898993#action_12898993
]
Chris Anderson commented on COUCHDB-855:
patch looks great! thanks so much. only change I'd suggest is removing this
change:
basicView : {
map : stringFun(function(doc) {
- emit(doc.integer, doc.string);
+ if (doc.integer && doc.string)
+emit(doc.integer, doc.string);
})
},
withReduce : {
map : stringFun(function(doc) {
- emit(doc.integer, doc.string);
+ if (doc.integer && doc.string)
+emit(doc.integer, doc.string);
}),
I know these guard conditions are good practice, but in real life there are
lots of "bad" views out there, so we should ensure the tests pass even without
the guards.
> New host manager
>
>
> Key: COUCHDB-855
> URL: https://issues.apache.org/jira/browse/COUCHDB-855
> Project: CouchDB
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Benoit Chesneau
>Assignee: Benoit Chesneau
> Fix For: 1.1
>
> Attachments:
> 0001-New-vhost-manager.-allows-dynamic-add-of-vhosts-with.patch
>
>
> New vhost manager. allows dynamic add of vhosts without restart, wildcard in
> vhost and specific functions in erlang by kind of domain. It also fix issue
> in etap test (160) .
> Find attached to this ticket the patch. It is also available in my github
> repo :
> http://github.com/benoitc/couchdb/commit/435c756cc6e687886cc7055302963f422cf0e161
> more details :
> This gen_server keep state of vhosts added to the ini and try to
> match the Host header (or forwarded) against rules built against
> vhost list.
> Declaration of vhosts take place in the configuration file :
> [vhosts]
> example.com = /example
> *.example.com = /example
> The first line will rewrite the rquest to display the content of the
> example database. This rule works only if the Host header is
> 'example.com' and won't work for CNAMEs. Second rule on the other hand
> match all CNAMES to example db. So www.example.com or db.example.com
> will work.
> The wildcard ('*') should always be the last in the cnames:
> "*.db.example.com = /" will match all cname on top of db
> examples to the root of the machine. (for now no rewriting is
> possible).
> By default vhosts redirection is handle by the function
> couch_httpd_vhost:redirect_to_vhost, but you could pass per vhost a
> specific function :
> "*.domain.com" = {Module, Func}"
> The function take the Mochiweb Request object and should return a new
> Mochiweb Request object.
> You could also change the default function to handle request by
> changing the setting `redirect_vhost_handler` in `httpd` section of
> the Ini:
> [httpd]
> redirect_vhost_handler = {Module, Fun}
> The function take 2 args : the mochiweb request object and the target
> path.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-854) Can 'make install' clean target directory prior to installation?
[ https://issues.apache.org/jira/browse/COUCHDB-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12897836#action_12897836 ] Chris Anderson commented on COUCHDB-854: I agree this would be nice. It seems to be our #1 install-related snag. > Can 'make install' clean target directory prior to installation? > > > Key: COUCHDB-854 > URL: https://issues.apache.org/jira/browse/COUCHDB-854 > Project: CouchDB > Issue Type: Wish > Components: Build System > Environment: Installing from source, all versions and platforms >Reporter: David Richardson > > Multiple versions of mochiweb in the erlang/lib directory can/will cause the > http stack to malfunction. Can the 'make install' process clean the > erlang/lib directory prior to installing a new build? > I'm not certain this isn't a bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-844) Documents missing after CouchDB restart
[
https://issues.apache.org/jira/browse/COUCHDB-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896278#action_12896278
]
Chris Anderson commented on COUCHDB-844:
We are investigating a potential issue with timezone bugs in Erlang as part of
the cause. Sascha, what is your TZ? Lim Yue Chaun is GMT +8.
Here is the TZ bug: https://issues.apache.org/jira/browse/COUCHDB-627
Also, can you run this command in the `erl` shell?
httpd_util:rfc1123_date(erlang:localtime()).
if it has a badarg error that could help us narrow down the cause.
Thanks
> Documents missing after CouchDB restart
> ---
>
> Key: COUCHDB-844
> URL: https://issues.apache.org/jira/browse/COUCHDB-844
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 1.0
> Environment: Debian Version 5.0.5, Linux *** 2.6.29-xs5.5.0.17 #1 SMP
> Mon Aug 3 17:37:37 UTC 2009 i686 GNU/Linux, XenServer Guest
>Reporter: Sascha Reuter
>Priority: Critical
>
> After a CouchDB restart, recently added/changed documents+designdocuments
> (min. 2 weeks timeline!) are missing and cant be accessed trough REST Calls /
> Futon.
> All documents that are still available trought REST/Futon only exist in old
> revisions.
> All documents/revisions can be found doing a manual search (less/egrep/...)
> in the datafile (/var/lib/couchdb/.couch)
> Example:
> strings dtap.couch | grep -i "226b2e6c-24b7-4336-92c7-257abf923b11"
> $226b2e6c-24b7-4336-92c7-257abf923b11h
> $226b2e6c-24b7-4336-92c7-257abf923b11l
> $226b2e6c-24b7-4336-92c7-257abf923b11l
> $226b2e6c-24b7-4336-92c7-257abf923b11l
> $226b2e6c-24b7-4336-92c7-257abf923b11l
> $226b2e6c-24b7-4336-92c7-257abf923b11l
> $226b2e6c-24b7-4336-92c7-257abf923b11l
> $226b2e6c-24b7-4336-92c7-257abf923b11l
> $226b2e6c-24b7-4336-92c7-257abf923b11l
> $226b2e6c-24b7-4336-92c7-257abf923b11h
> $226b2e6c-24b7-4336-92c7-257abf923b11h
> curl http://localhost:5984/dtap/226b2e6c-24b7-4336-92c7-257abf923b11
> {"error":"not_found","reason":"missing"}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-141) Replication should respect since=N seq-num parameter
[ https://issues.apache.org/jira/browse/COUCHDB-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson updated COUCHDB-141: --- Summary: Replication should respect since=N seq-num parameter (was: Short-Cut replication initialisation for large databases that are guaranteed to be equal) Issue Type: Improvement (was: New Feature) Affects Version/s: 1.0 (was: 0.9) Description: The changes feed has a since=Seq param which can be used to start listening somewhere other than the beginning of the database history. The replicator should respect this option as well. This can also be used by administrators who are bringing a CouchDB instance up from a file that was physically copied between servers. was:In a situation where a large database is made available on multiple nodes by copying over the .couch file and where multi-master-replication should keep all nodes in sync, the initial replication in each direction takes quite some time, trying to determine if all databases are in the same state. When we copy the .couch files, they are guaranteed to be equal. It would be nice to be able to tell CouchDB that it doesn't actually have to iterate through all dbs and just accept the fact that we tell it that they are equal. renamed this ticket to for a feature that is more flexible than the old one. > Replication should respect since=N seq-num parameter > > > Key: COUCHDB-141 > URL: https://issues.apache.org/jira/browse/COUCHDB-141 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Affects Versions: 1.0 >Reporter: Jan Lehnardt >Priority: Minor > > The changes feed has a since=Seq param which can be used to start listening > somewhere other than the beginning of the database history. The replicator > should respect this option as well. > This can also be used by administrators who are bringing a CouchDB instance > up from a file that was physically copied between servers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-832) Handling HTTP OPTIONS method
[ https://issues.apache.org/jira/browse/COUCHDB-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893795#action_12893795 ] Chris Anderson commented on COUCHDB-832: Could you describe the nature of this patch? I'm vaguely familiar with the use of OPTIONS for pre-flight testing of the acceptance of cross-domain requests. Does this patch open up CouchDB to all cross-domain requests? Does that mean if you are logged into a couch as an admin, and then you visit a malicious site, they can delete all your databases / trigger outbound replication / otherwise cause mayhem? Or is this patch more controlled? I'd imagine if we are going to support this we'll need a way to configure which domains are allowed to trigger cross domain requests. Maybe I'm totally off-base... please let us know what you think about these issues. > Handling HTTP OPTIONS method > > > Key: COUCHDB-832 > URL: https://issues.apache.org/jira/browse/COUCHDB-832 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.0 >Reporter: Stanisław > > Method OPTIONS is not allowed, which disables ability for cross-site > XMLHttpRequest (other than GET) within the browser (see: > http://www.w3.org/TR/cors) > Current headers: > curl -X OPTIONS http://localhost:5984 -v > ... > < HTTP/1.1 405 Method Not Allowed > < Server: CouchDB/1.0.0 (Erlang OTP/R13B) > < Date: Thu, 22 Jul 2010 17:56:59 GMT > < Content-Type: text/plain;charset=utf-8 > < Content-Length: 64 > < Cache-Control: must-revalidate > < Allow: GET,HEAD > Expected headers: > HTTP/1.1 200 OK > Access-Control-Allow-Methods: POST, GET, OPTIONS > Access-Control-Allow-Headers: X-PINGOTHER > Stan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-141) Short-Cut replication initialisation for large databases that are guaranteed to be equal
[ https://issues.apache.org/jira/browse/COUCHDB-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893749#action_12893749 ] Chris Anderson commented on COUCHDB-141: the challenge with this ticket is determining if 2 databases are copies of the same file. maybe we should think about this differently. if instead of trying to automatically suss out which seq num the dbs remain equal up to, we could much more easily add a parameter to replication like source_start_seq : N, this would start replication from the source at that sequence number. This can be used to accomplish the goals of this ticket (without any magic) and is also generally useful for other scenarios. If I don't get any push back on this suggestion, I'll rename the ticket in a few days. (Or you can, if I forget to.) > Short-Cut replication initialisation for large databases that are guaranteed > to be equal > > > Key: COUCHDB-141 > URL: https://issues.apache.org/jira/browse/COUCHDB-141 > Project: CouchDB > Issue Type: New Feature > Components: Database Core >Affects Versions: 0.9 >Reporter: Jan Lehnardt >Priority: Minor > > In a situation where a large database is made available on multiple nodes by > copying over the .couch file and where multi-master-replication should keep > all nodes in sync, the initial replication in each direction takes quite some > time, trying to determine if all databases are in the same state. When we > copy the .couch files, they are guaranteed to be equal. It would be nice to > be able to tell CouchDB that it doesn't actually have to iterate through all > dbs and just accept the fact that we tell it that they are equal. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892874#action_12892874 ] Chris Anderson commented on COUCHDB-837: stale=ok was carefully and intentionally chosen by me to reflect the crappy consistency guarantees you get with this query. If it had it to do over again I'd chose stale=meh > Adding stale=partial > > > Key: COUCHDB-837 > URL: https://issues.apache.org/jira/browse/COUCHDB-837 > Project: CouchDB > Issue Type: Improvement > Environment: all released and unreleased versions >Reporter: Filipe Manana >Assignee: Filipe Manana > Attachments: stale_partial.patch > > > Inspired by Matthias' latest post, at > http://www.paperplanes.de/2010/7/26/10_annoying_things_about_couchdb.html, > section "Views are updated on read access", I added a new value to the > "stale" option named "partial" (possibly we need to find a better name). > It behaves exactly like "stale=ok" but after replying to the client, it > triggers a view update in the background. > Patch attached. > If no one disagrees this isn't a good feature, or suggest a better parameter > value name, I'll commit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892617#action_12892617 ] Chris Anderson commented on COUCHDB-837: Last bikeshed perspective from me: stale=ok for current behavior, and stale=lazy or stale=freshen for the one that updates the views in the background. I'm not that into a separate param for this, (I've already said I think the current behavior is a bug), because update_index makes zero sense on a non-stale query. I liked 'ok' because it was non-committal, I think 'freshen' or 'lazy' maintains that vibe, while being descriptive of the effect. I'm gonna leave this up to Filipe to implement, it's his choice since he's writing the patch. > Adding stale=partial > > > Key: COUCHDB-837 > URL: https://issues.apache.org/jira/browse/COUCHDB-837 > Project: CouchDB > Issue Type: Improvement > Environment: all released and unreleased versions >Reporter: Filipe Manana >Assignee: Filipe Manana > Attachments: stale_partial.patch > > > Inspired by Matthias' latest post, at > http://www.paperplanes.de/2010/7/26/10_annoying_things_about_couchdb.html, > section "Views are updated on read access", I added a new value to the > "stale" option named "partial" (possibly we need to find a better name). > It behaves exactly like "stale=ok" but after replying to the client, it > triggers a view update in the background. > Patch attached. > If no one disagrees this isn't a good feature, or suggest a better parameter > value name, I'll commit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892541#action_12892541 ] Chris Anderson commented on COUCHDB-837: you know -- why doesn't stale=ok just trigger a reindex also? it just serves the reply w/o waiting for the reindex to happen. there's no reason at all that you we should have an api where you intentionally avoid updating an index. (the point of stale=ok is a low latency response, not to avoid indexing) I think just changing the behavior of stale=ok to also trigger an index update is the best solution. > Adding stale=partial > > > Key: COUCHDB-837 > URL: https://issues.apache.org/jira/browse/COUCHDB-837 > Project: CouchDB > Issue Type: Improvement > Environment: all released and unreleased versions >Reporter: Filipe Manana >Assignee: Filipe Manana > Attachments: stale_partial.patch > > > Inspired by Matthias' latest post, at > http://www.paperplanes.de/2010/7/26/10_annoying_things_about_couchdb.html, > section "Views are updated on read access", I added a new value to the > "stale" option named "partial" (possibly we need to find a better name). > It behaves exactly like "stale=ok" but after replying to the client, it > triggers a view update in the background. > Patch attached. > If no one disagrees this isn't a good feature, or suggest a better parameter > value name, I'll commit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892499#action_12892499 ] Chris Anderson commented on COUCHDB-837: stale=okgo > Adding stale=partial > > > Key: COUCHDB-837 > URL: https://issues.apache.org/jira/browse/COUCHDB-837 > Project: CouchDB > Issue Type: Improvement > Environment: all released and unreleased versions >Reporter: Filipe Manana >Assignee: Filipe Manana > Attachments: stale_partial.patch > > > Inspired by Matthias' latest post, at > http://www.paperplanes.de/2010/7/26/10_annoying_things_about_couchdb.html, > section "Views are updated on read access", I added a new value to the > "stale" option named "partial" (possibly we need to find a better name). > It behaves exactly like "stale=ok" but after replying to the client, it > triggers a view update in the background. > Patch attached. > If no one disagrees this isn't a good feature, or suggest a better parameter > value name, I'll commit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-833) Use Takanori Ishikawa's JS SHA1 implementation which doesn't pollute the global namespace
[ https://issues.apache.org/jira/browse/COUCHDB-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891477#action_12891477 ] Chris Anderson commented on COUCHDB-833: patch doesn't apply cleanly (might be because I did the json2.js update beforehand direct from json.org) Can you repost the patch against latest trunk, or a link to your git repo so I can clone directly? Thanks! Chris > Use Takanori Ishikawa's JS SHA1 implementation which doesn't pollute the > global namespace > - > > Key: COUCHDB-833 > URL: https://issues.apache.org/jira/browse/COUCHDB-833 > Project: CouchDB > Issue Type: Improvement > Components: Futon >Reporter: Devin Torres >Priority: Trivial > Attachments: better_js_sha1.patch > > Original Estimate: 0.02h > Remaining Estimate: 0.02h > > The current implementation by Paj is slow and pollutes the global namespace > with variables and functions. This implementation only exports the SHA1 > module and also happens to be up to 3 times faster as an added bonus. See > http://bit.ly/9wjjRG for benchmarks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-53) Incorporating JSearch to CouchDB
[
https://issues.apache.org/jira/browse/COUCHDB-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891260#action_12891260
]
Chris Anderson commented on COUCHDB-53:
---
I'll say I think this is important.
It would allow "dynamic queries". That is, it makes it possible to run queries
you didn't think of, without running an entire map reduce job.
The absence of this is a big reason people shy away from CouchDB.
Just sayin'
> Incorporating JSearch to CouchDB
>
>
> Key: COUCHDB-53
> URL: https://issues.apache.org/jira/browse/COUCHDB-53
> Project: CouchDB
> Issue Type: New Feature
> Components: Full-Text Search
> Environment: JSearch is developed in Java
>Reporter: Jun Rao
>Assignee: Paul Joseph Davis
>Priority: Minor
> Attachments: jsearch_full.tgz
>
>
> JSearch is a prototype that we developed for indexing and searching Json
> documents, and we are enthusiastic about contributing it to CouchDB. JSearch
> converts a given Json document to a Lucene document for indexing. The
> conversion is lossless and preserves all structural information in the
> original Json document. We achieve that by storing the encoding of Json
> structures in the payload of the posting list in a Lucene index. JSearch has
> a simple query language that combines fulltext search and structural
> querying. To qualify as a match, a document has to match both the JSON
> structures as well as the Boolean constraints specified in the query. Suppose
> that we have indexed the following two JSON documents:
>d1={ A: [ { B: "b1", C: "c1" },
> { B: "b2", C: "c2" },
>]
> }
>d2={ A: [ { B: "b1", C: "c2" },
> { B: "b2", C: "c1" },
>]
> }
> One can issue the following two JSeach queries.
>P={ A: [ { B: "b1" && C: "c1" } ] }
>Q={ A: [ { B: "b1"} && {C: "c1" } ] }
> Query P ("&&" specifies conjunction) matches d1, but not d2. The reason is
> that d2 doesn't have the proper B and C fields within the same JSON object.
> On the other hand, query Q matches both d1 and d2, since it doesn't require
> the B field and the C field to be in the same JSON object.
> Here is a summary of the querying features in JSearch
> 1. arbitrary conjunctive and disjunctive constraints
> 2. text search on atomic values of string type
> 3. range constraints on atomic values (only those of string and long types
> are currently supported)
> 4. document level matching
> The easiest way to know more about JSeach is to give it a try. Download the
> attached tgz file. Follow the readme file in it and try some of the examples.
> The attachment also includes all Java source code (I can provide more
> technical details if needed). I am very interested in your feedback. Does
> JSearch fit into CouchDB? What other features are needed? How should JSearch
> be integrated (from Jan's mail, it seems that some infrastructure is already
> in-place)? Thanks,
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-831) badarity
[
https://issues.apache.org/jira/browse/COUCHDB-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-831.
--
Resolution: Fixed
added a proper 404 message in r966685
> badarity
>
>
> Key: COUCHDB-831
> URL: https://issues.apache.org/jira/browse/COUCHDB-831
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: mac os x
>Reporter: Harry Vangberg
>
> I have an empty database with nothing but this design document:
> {
>"_id": "_design/foo",
>"_rev": "1-19b6ac05cd5e878bbe8193c3fbce57bb",
>"language": "javascript",
>"views": {
>"foo": {
>"map": "function(doc) {emit(1,2);}"
>}
>}
> }
> Which fails miserably.
> $ curl http://127.0.0.1:5984/argh/_design/foo/_views/bar
> [Thu, 22 Jul 2010 13:27:53 GMT] [error] [<0.1015.0>] Uncaught error in HTTP
> request: {error,
> {badarity,
> {#Fun,
>[{httpd,
> {mochiweb_request,#Port<0.2266>,'GET',
> "/argh/_design/foo/_views/bar",
> {1,1},
> {3,
>{"user-agent",
> {'User-Agent',
> "curl/7.19.7
> (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3"},
> {"host",
> {'Host',"127.0.0.1:5984"},
> {"accept",{'Accept',"*/*"},nil,nil},
> nil},
> nil}}},
> "127.0.0.1",'GET',
> [<<"argh">>,<<"_design">>,<<"foo">>,
> <<"_views">>,<<"bar">>],
> {dict,5,16,16,8,80,48,
> {[],[],[],[],[],[],[],[],[],[],[],[],[],
>[],[],[]},
> {{[[<<"_design">>|
> #Fun]],
> [],
> [[<<"_view_cleanup">>|
> #Fun]],
> [],[],[],[],[],
> [[<<"_compact">>|
> #Fun]],
> [],[],
> [[<<"_temp_view">>|
> #Fun]],
> [[<<"_changes">>|
> #Fun]],
> [],[],[]}}},
> {user_ctx,null,
> [<<"_admin">>],
> <<"{couch_httpd_auth,
> default_authentication_handler}">>},
> undefined,
> {dict,6,16,16,8,80,48,
> {[],[],[],[],[],[],[],[],[],[],[],[],[],
>[],[],[]},
> {{[],
> [[<<"_show">>|
> #Fun]],
> [[<<"_info">>|
> #Fun],
> [<<"_list">>|
> #Fun]],
> [[<<"_update">>|
> #Fun]],
> [],[],[],[],[],
> [[<<"_rewrite">>|
> #Fun]],
> [],[],[],
> [[<<"_view">>|
> #Fun]],
> [],[]}}},
> undefined,#Fun,
> {dict,13,16,16,8,80,48,
> {[],[],[],[],[],[],[],[],[],[],[],[],[],
>[],[],[]},
> {{[[<<"_restart">>|
> #Fun],
> [<<"_replicate">>|
> #Fun]],
> [[<<"_active_tasks">>|
>
[jira] Closed: (COUCHDB-815) Non-standard HTTP methods for view handlers (AKA WebDAV is b0rken) [PATCH]
[
https://issues.apache.org/jira/browse/COUCHDB-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-815.
--
Resolution: Fixed
Forgot to mark this as closed. Thanks!
> Non-standard HTTP methods for view handlers (AKA WebDAV is b0rken) [PATCH]
> --
>
> Key: COUCHDB-815
> URL: https://issues.apache.org/jira/browse/COUCHDB-815
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 1.0
> Environment: Erlang/OTP R13B04
>Reporter: Jason Smith
>Priority: Minor
> Attachments: allow_http_method_convert_to_binary.patch,
> bad_allow_any_http_method.patch
>
>
> CouchDB prevents the new view server handler methods, _show, _update, etc.
> from handling unknown HTTP methods. This prevents Couch apps from being able
> to implement extensions to the HTTP specification or to add
> application-specific methods to HTTP, violating the spirit of _show and
> _update.
> For example, it is not possible to make a CouchApp WebDAV server because
> _show and _list must support the PROPFIND method.
> In couch_httpd:handle_request_int/5, the response from Mochi is coerced to an
> atom if and only if the atom already exists (using
> couch_util:to_existing_atom/1). That is an odd whitelist, to say the least:
> $ curl localhost:5984 -X PROPFIND # Crashes mochiweb when
> to_existing_atom throws badarg
> curl: (52) Empty reply from server
> $ curl localhost:5984 -X list_to_binary # Any atom works
> {"error":"method_not_allowed","reason":"Only GET,HEAD allowed"}
> Considering the cURL commands above, I filed this as a bug, not a feature. I
> will explore some options and submit patches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-829) Denial of Service vulnerability in rewriter
[
https://issues.apache.org/jira/browse/COUCHDB-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-829.
--
Resolution: Fixed
thanks, fixed in r965667
> Denial of Service vulnerability in rewriter
> ---
>
> Key: COUCHDB-829
> URL: https://issues.apache.org/jira/browse/COUCHDB-829
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 1.0
> Environment: CouchDB trunk, erl R13B04
>Reporter: Jason Smith
>
> Untrusted, unsanitized user input should not be converted to atoms because it
> allows the user to fill up the atom table in the VM, wasting memory and
> eventually causing a couchdb crash.
> If rewriting is enabled (which it is by default), and if an attacker knows a
> database and ddoc name (even if the ddoc has no _rewrite rules), the attacker
> can permanently enter atoms into system.
> I have not exhaustively audited couch_httpd_rewrite.erl but for instance
> handle_rewrite_req/3 converts all URL query keys to atoms.
> [info] [<0.38.0>] Apache CouchDB has started on http://0.0.0.0:5984/
> 1> erlang:list_to_existing_atom("do_i_exist").
> ** exception error: bad argument
> in function list_to_existing_atom/1
> called as list_to_existing_atom("do_i_exist")
> $ curl -X PUT localhost:5984/ex
> {"ok":true}
> $ curl -X PUT localhost:5984/ex/_design/ex -d {}
> {"ok":true,"id":"_design/ex","rev":"1-967a00dff5e02add41819138abb3284d"}
> $ curl http://localhost:5984/ex/_design/ex/_rewrite?do_i_exist=blah
> {"error":"rewrite_error","reason":"Invalid path."}
> 2> [info] [<0.109.0>] 127.0.0.1 - - 'GET'
> /ex/_design/ex/_rewrite?do_i_exist=blah 404
> 2> erlang:list_to_existing_atom("do_i_exist").
> do_i_exist
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-828) When Issuing a Get Request with Content-Type: application/x-www-form-urlencoded an error is thrown
[ https://issues.apache.org/jira/browse/COUCHDB-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889263#action_12889263 ] Chris Anderson commented on COUCHDB-828: Can you provide more details as to which URL you were requesting? Maybe sharing the JS code you are using to do this would help as well. Thanks! Chris > When Issuing a Get Request with Content-Type: > application/x-www-form-urlencoded an error is thrown > -- > > Key: COUCHDB-828 > URL: https://issues.apache.org/jira/browse/COUCHDB-828 > Project: CouchDB > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Talib > > When doing an AJAX GET Request, the content type is set to > application/x-www-form-urlencoded, the request fails. > Removing the "Content-Type: application/x-www-form-urlencoded" header makes > the request success. > Here is what the headers look like for a failed request. > Connection: keep-alive > User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) > AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4 > X-Requested-With: XMLHttpRequest > Content-Type: application/x-www-form-urlencoded > Accept: application/json, text/javascript, */* -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COUCHDB-825) _changes "compaction"
[ https://issues.apache.org/jira/browse/COUCHDB-825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson resolved COUCHDB-825. Resolution: Won't Fix Harry, The replication model (and the way _changes would work on a large cluster) mean that it can't ever do this. We don't replicate all intermediate states, we just replicate the current state. Also, if compaction occurs between your delete and the time the next line happens in _changes (imagine a slow client) there may be nothing to show. If you tell us more about your use case maybe we can help you find the right way to support it with CouchDB. Chris > _changes "compaction" > - > > Key: COUCHDB-825 > URL: https://issues.apache.org/jira/browse/COUCHDB-825 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 0.11 >Reporter: Harry Vangberg > Attachments: test_all_changes.js > > > If I create a document, delete it again and after that pulls the _changes > feed, it only has one result, for the revision where the document it is > deleted. I would expect it to have two results: one for the creation and one > for the deletion. On IRC I was told it shouldn't behave like that, and it is > kinda crucial for my use of the _changes feed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-819) rev 958039 breaks "Save Document"
[
https://issues.apache.org/jira/browse/COUCHDB-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-819.
--
Resolution: Fixed
thanks, this was due to an incomplete backport, and it should be fixed now. Let
us know if the problem is still there in the 0.11.x branch
> rev 958039 breaks "Save Document"
> -
>
> Key: COUCHDB-819
> URL: https://issues.apache.org/jira/browse/COUCHDB-819
> Project: CouchDB
> Issue Type: Bug
> Components: Futon
>Affects Versions: 0.11
> Environment: Ubuntu 10.04, amd64
>Reporter: Nome Consulting
>
> The following patch fixes a bug introduced by rev 958039. fullCommit is not
> defined and because of it some browsers break at line 362. beforeSend is not
> used in saveDoc.
> Index: share/www/script/jquery.couch.js
>
>
> ===
>
>
> --- share/www/script/jquery.couch.js(revision 961023)
>
>
> +++ share/www/script/jquery.couch.js(working copy)
>
>
> @@ -359,7 +359,7 @@
>
>
> saveDoc: function(doc, options) {
>
>
>options = options || {};
>
>
>var db = this;
>
>
> - var beforeSend = fullCommit(options);
>
>
> + //var beforeSend = fullCommit(options);
>
>
>if (doc._id === undefined) {
>
>
> var method = "POST";
>
>
> var uri = this.uri;
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-817) Natively support coffeescript
[ https://issues.apache.org/jira/browse/COUCHDB-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885571#action_12885571 ] Chris Anderson commented on COUCHDB-817: Here's a link to a Ruby query server: http://github.com/mattly/couchdb-ruby-query-server Also, here is the test for the current JS and Erlang query servers: http://svn.apache.org/repos/asf/couchdb/trunk/test/view_server/query_server_spec.rb > Natively support coffeescript > - > > Key: COUCHDB-817 > URL: https://issues.apache.org/jira/browse/COUCHDB-817 > Project: CouchDB > Issue Type: New Feature >Reporter: Matt Parker > > i'd love to be able to put coffeescript map and reduce function/files > directly into my ddoc, instead of having to compile them first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COUCHDB-817) Natively support coffeescript
[ https://issues.apache.org/jira/browse/COUCHDB-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson resolved COUCHDB-817. Resolution: Later I agree. Coffeescript is a great fit for CouchDB, but I think it's more appropriate for tooling to handle this, not built-in code. I would like to see a contrib/ directory in the project for things like alternate-language view servers. We'll be able to move forward on stuff like this as soon as 1.0 is out. Marking this as Later, but it's not too soon to start working on a Coffeescript query server if you are inclined. > Natively support coffeescript > - > > Key: COUCHDB-817 > URL: https://issues.apache.org/jira/browse/COUCHDB-817 > Project: CouchDB > Issue Type: New Feature >Reporter: Matt Parker > > i'd love to be able to put coffeescript map and reduce function/files > directly into my ddoc, instead of having to compile them first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-720) Pull replication fails due to "401 Authentication required" while push replication works fine
[ https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885037#action_12885037 ] Chris Anderson commented on COUCHDB-720: So it seems the 301 redirect following is the issue, not the authentication. We should verify that this is fixed in trunk before we cut 1.0 > Pull replication fails due to "401 Authentication required" while push > replication works fine > - > > Key: COUCHDB-720 > URL: https://issues.apache.org/jira/browse/COUCHDB-720 > Project: CouchDB > Issue Type: Bug > Components: Futon, HTTP Interface, Replication >Affects Versions: 0.10.1, 0.11 > Environment: Remote server having Nginx reverse proxy and basic > authentication enabled >Reporter: Jochen Kempf >Priority: Blocker > > Pull replication fails using both Futon Replicator and http request throwing > an "401 Authentication required" error. This just happens when design > documents are existent. > Push replication on the other hand works fine. > See used code here: http://gist.github.com/364072 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-683) Missing WWW-Authenticate header (regression)
[
https://issues.apache.org/jira/browse/COUCHDB-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-683.
--
Resolution: Not A Problem
This is configurable. See local.ini for instructions.
> Missing WWW-Authenticate header (regression)
>
>
> Key: COUCHDB-683
> URL: https://issues.apache.org/jira/browse/COUCHDB-683
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.11
>Reporter: Matt Goodall
>
> CouchDB does not send a "WWW-Authenticate" header in the 401 response
> (CouchDB 0.10.x) . May break many HTTP clients.
> $ curl -i -X "PUT" http://localhost:5984/foo
> HTTP/1.1 401 Unauthorized
> Server: CouchDB/0.11.0bf93cb9b-git (Erlang OTP/R13B)
> Date: Fri, 05 Mar 2010 12:40:28 GMT
> Content-Type: text/plain;charset=utf-8
> Content-Length: 64
> Cache-Control: must-revalidate
> {"error":"unauthorized","reason":"You are not a server admin."}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-161) Range Request support for attachments
[ https://issues.apache.org/jira/browse/COUCHDB-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884951#action_12884951 ] Chris Anderson commented on COUCHDB-161: I've seen a few requests for this. It should be a simple patch to make the API available. Maybe slightly more complicated to avoid scanning all the attachment prior to the range start, but that's an optimization. > Range Request support for attachments > - > > Key: COUCHDB-161 > URL: https://issues.apache.org/jira/browse/COUCHDB-161 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface >Affects Versions: 0.11 >Reporter: Dean Landolt >Assignee: Jan Lehnardt >Priority: Minor > Fix For: 0.12 > > > Support for byte ranges in attachment requests (a la > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35) would allow > couch to be a more robust data store for media-heavy applications, for > instance, streaming audio or video. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-647) Zero size DB files are created, which make CouchDB crash.
[ https://issues.apache.org/jira/browse/COUCHDB-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-647. -- Resolution: Fixed this was fixed in r959791 thanks! > Zero size DB files are created, which make CouchDB crash. > - > > Key: COUCHDB-647 > URL: https://issues.apache.org/jira/browse/COUCHDB-647 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.9.1, 0.10 > Environment: Ubuntu Hardy >Reporter: eric casteleijn >Priority: Critical > Attachments: couch_file_logging.patch > > > Our production server crashed with the following fragment in the error log > http://friendpaste.com/3VfsxGrH2XxvkqE3XQA4oy > It appears that this is due to a corrupted or zero size database file. > Chris Anderson suggested the attached patch to improve the logging in this > case. > doppler came up with a script that reproduces the crash: > touch > /Applications/CouchDBX-0.10.1-R13B03-Leopard.app/Contents/Resources/couchdbx-core/couchdb/var/lib/couchdb/test.couch > while true ; do curl -X GET http://localhost:5984/test ; done > NOTE: On the server that crashed we do not manipulate database files in any > other way than calling the REST interface, so it is still a mystery how zero > sized dbs get created. I will investigate by digging through the logs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-489) Ability to set continous replication from Futon
[ https://issues.apache.org/jira/browse/COUCHDB-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-489. -- Resolution: Fixed this got fixed in the lead up to 1.0 > Ability to set continous replication from Futon > --- > > Key: COUCHDB-489 > URL: https://issues.apache.org/jira/browse/COUCHDB-489 > Project: CouchDB > Issue Type: Improvement > Components: Futon, Replication >Affects Versions: 0.12 > Environment: Mac OS 10 >Reporter: David Coallier >Priority: Minor > Fix For: 0.12 > > Attachments: COUCHDB-489.2.patch, COUCHDB-489.3.patch, > COUCHDB-489.patch, COUCHDB-489.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > This patch gives you the ability to set continous replication from Futon when > replicating to another server. There are 2 typeof(undefined) that you can see > in the code which are there to make sure that adding a new parameter to > CouchDB.replicate doesn't break legacy code and other parts of the system > that may be using it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-776) _replicator DB
[ https://issues.apache.org/jira/browse/COUCHDB-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884768#action_12884768 ] Chris Anderson commented on COUCHDB-776: This applies cleaning and all tests pass for me. And it looks stable. I think it will be worth waiting to apply this until after 1.0 is branched, not because I have any worries about the stability, but because I have a feeling people will be have useful feedback about some of the validation rules, and maybe other details about the API. I think it'd be healthy for the feature to sit in trunk and get some feedback before going into a release. > _replicator DB > -- > > Key: COUCHDB-776 > URL: https://issues.apache.org/jira/browse/COUCHDB-776 > Project: CouchDB > Issue Type: New Feature > Components: Replication > Environment: trunk >Reporter: Filipe Manana >Assignee: Filipe Manana > > As discussed in the mailing list thread "_replicator DB" (May) - > http://mail-archives.apache.org/mod_mbox/couchdb-dev/201005.mbox/%3caanlktilfnng9fuxuxjb5cazo6__mjaogpiw4xtuzp...@mail.gmail.com%3e > The patch follows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-649) Users are unable to login to futon when require_valid_user is set to true
[ https://issues.apache.org/jira/browse/COUCHDB-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884323#action_12884323 ] Chris Anderson commented on COUCHDB-649: you should be able to uncomment 1 line in local.ini to get Couch to send the header that might help with login. Ben, can you try this too? The line is: ; Uncomment next line to trigger basic-auth popup on unauthorized requests. ;WWW-Authenticate = Basic realm="administrator" > Users are unable to login to futon when require_valid_user is set to true > - > > Key: COUCHDB-649 > URL: https://issues.apache.org/jira/browse/COUCHDB-649 > Project: CouchDB > Issue Type: Bug > Components: Futon >Reporter: Ben Schwarz >Assignee: Chris Anderson >Priority: Minor > > Using basic auth to login to futon doesn't work. A cookie is required. > This presents an annoying / difficult user experience. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-393) Cannot discover currently running http port if ini file specifies port 0
[ https://issues.apache.org/jira/browse/COUCHDB-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883706#action_12883706 ] Chris Anderson commented on COUCHDB-393: Benoit's patch looks good to me. I'd be happy to see it in 1.0. Care to commit it? > Cannot discover currently running http port if ini file specifies port 0 > > > Key: COUCHDB-393 > URL: https://issues.apache.org/jira/browse/COUCHDB-393 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 0.9 > Environment: Ubuntu 9.04 >Reporter: Stuart Langridge >Assignee: Noah Slater >Priority: Blocker > Fix For: 0.12 > > Attachments: couch_uri.patch, couchctl.patch > > > It is currently not possible, if the ini file specifies port 0 as the http > port (so that the OS chooses a random port) to discover which port the OS > actually chose. > It would be nice if the currently running port was made available in the > statusline output (couchdb -s), but a log statement would be adequate; some > way that an external script can discover which port a running CouchDB is > listening on. > Edited discussion from #couchdb: > aquarius: well at a glance it appears couch_http passes the 0 to > mochiweb_http which passes it to the mochiweb_socket_server, which passes it > to gen_tcp, an erlang module that lets the underlying OS assign it. > mochiweb_socket_server then grabs that port and stores it. It has a get > method to retrieve properties but that needs to be exposed to mochiweb_http > so it would take a little work to do it. It's probably a JIRA ticket, unless > someone else sees a quicker approach > bitdiddle: you got that far and didn't find it? > davisp: is there a better way to find the port? > oh, is that not the bind port? > I was just thinking a log statement > davisp: the problem is if you specify 0 as the bind port (so the > OS chooses a port), how do you find out what was chosen? > aquarius: you have to look at the port returned by the socket > aquarius: in other words, CouchDB was never written to do that > AFAIK > davisp: I found it, just needs some work to expose it > aquarius: and by do that, I mean, we never put in a statement to log > that > mochiweb_http is the module that needs to bubble it up > davisp: I don't really mind whether it's a log statement or it's > exposed to couchdb -s (the latter seems tidier to me, but whichever), I just > want to be able to start couch on port 0 and then later find out which port > got chosen :) > aquarius: for the time being you can use something like netstat or > lsof, but we'll get a log statement in there or something -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-812) implement randomization in views resultset
[
https://issues.apache.org/jira/browse/COUCHDB-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883180#action_12883180
]
Chris Anderson commented on COUCHDB-812:
I agree. This isn't done by CouchDB, because it will incur roughly the same
big-O cost to do random on the server, as it would on the client.
To solve this, use a view with random keys, and paginate through it. You'll
have static view, so you can only use it once, but it will be in random order.
With smaller datasets this would be an OK place to use a temp view.
> implement randomization in views resultset
> --
>
> Key: COUCHDB-812
> URL: https://issues.apache.org/jira/browse/COUCHDB-812
> Project: CouchDB
> Issue Type: Wish
> Components: Database Core
>Affects Versions: 0.11
> Environment: CouchDB
>Reporter: Mickael Bailly
>Priority: Minor
>
> This is a proposal for a new feature in CouchDB : allow a randomization of
> rows in a view response. We can for example add a randomize query parameter...
> This request would probably not return the same results for the same request.
> As an example :
> GET /db/_design/doc/_view/example :
> {
> ..
> rows: [
> {key: 1 ...},
> {key: 2 ...},
> {key: 3 ...}
> ]
> }
> GET /db/_design/doc/_view/example?randomize=true :
> {
> ..
> rows: [
> {key: 2 ...},
> {key: 3 ...},
> {key: 1 ...}
> ]
> }
> GET /db/_design/doc/_view/example?randomize=true :
> {
> ..
> rows: [
> {key: 1 ...},
> {key: 3 ...},
> {key: 2 ...}
> ]
> }
> This is a feature hard to implement client-side (but by reading all doc ids
> and use client-side random function). It's implemented by the RDBMS from
> ages, probably for the very same reasons : if we should read all the rows
> client-side to random-select some of them, performances are awful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-749) CouchDB does not persist large values of Numbers correctly.
[
https://issues.apache.org/jira/browse/COUCHDB-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882256#action_12882256
]
Chris Anderson commented on COUCHDB-749:
I've patched mochijson2.erl again to give it the proper behavior. The patch is
tiny. I'll try sending it upstream and see what we get.
diff --git a/src/mochiweb/mochijson2.erl b/src/mochiweb/mochijson2.erl
index 66f68bf..111c37b 100644
--- a/src/mochiweb/mochijson2.erl
+++ b/src/mochiweb/mochijson2.erl
@@ -98,11 +98,8 @@ json_encode(false, _State) ->
<<"false">>;
json_encode(null, _State) ->
<<"null">>;
-json_encode(I, _State) when is_integer(I) andalso I >= -2147483648 andalso I
=< 2147483647 ->
-%% Anything outside of 32-bit integers should be encoded as a float
-integer_to_list(I);
json_encode(I, _State) when is_integer(I) ->
-mochinum:digits(float(I));
+integer_to_list(I);
json_encode(F, _State) when is_float(F) ->
mochinum:digits(F);
json_encode(S, State) when is_binary(S); is_atom(S) ->
> CouchDB does not persist large values of Numbers correctly.
> ---
>
> Key: COUCHDB-749
> URL: https://issues.apache.org/jira/browse/COUCHDB-749
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.11
> Environment: All
>Reporter: Jarrod Roberson
>
> All the following operations exhibit the same bug, large numbers don't get
> persisted correctly. They get something added to them for some reason.
> 9223372036854775807 == java.lang.Long.MAX_VALUE
> 1: go into Futon, create a new document and create a new field and enter the
> number 9223372036854775807, click the green check mark, the number changes to
> 9223372036854776000 even before you save it.
> 2.curl -X PUT http://localhost:5984/test/longTest -d '{"value":
> 9223372036854775807}', the number gets persisted as 9223372036854776000
> trying to persist System.currentTimeMilliseconds() from java causes the same
> thing to happen occasionally.
> This seems to be a pretty serious bug if I can't trust that my data is not
> being corrupted when submitted to the database.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-749) CouchDB does not persist large values of Numbers correctly.
[
https://issues.apache.org/jira/browse/COUCHDB-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-749.
--
Resolution: Fixed
fixed in 957656
> CouchDB does not persist large values of Numbers correctly.
> ---
>
> Key: COUCHDB-749
> URL: https://issues.apache.org/jira/browse/COUCHDB-749
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.11
> Environment: All
>Reporter: Jarrod Roberson
>
> All the following operations exhibit the same bug, large numbers don't get
> persisted correctly. They get something added to them for some reason.
> 9223372036854775807 == java.lang.Long.MAX_VALUE
> 1: go into Futon, create a new document and create a new field and enter the
> number 9223372036854775807, click the green check mark, the number changes to
> 9223372036854776000 even before you save it.
> 2.curl -X PUT http://localhost:5984/test/longTest -d '{"value":
> 9223372036854775807}', the number gets persisted as 9223372036854776000
> trying to persist System.currentTimeMilliseconds() from java causes the same
> thing to happen occasionally.
> This seems to be a pretty serious bug if I can't trust that my data is not
> being corrupted when submitted to the database.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-809) Saving an attachment stub with a missing revpos field results in a 412 Precondition Failed (missing_stub) error
[
https://issues.apache.org/jira/browse/COUCHDB-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-809.
--
Resolution: Fixed
applied in r957653. thanks!
> Saving an attachment stub with a missing revpos field results in a 412
> Precondition Failed (missing_stub) error
> ---
>
> Key: COUCHDB-809
> URL: https://issues.apache.org/jira/browse/COUCHDB-809
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.11
> Environment: Mac OS X 10.6, CouchDBX 0.11.0
>Reporter: Caleb Land
>
> If you PUT a document with attachment stubs that are missing the revpos
> field, a 412 Precondition Failed error is raised with the message:
> {"error":"missing_stub","reason":"id:test, name:graph.html"}
> If a revpos is provided, then everything works ok.
> Here is some sample ruby code that demonstrates this:
> http://gist.github.com/450323
> I think the only field that should be required for an attachment is the
> "stub" field.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-807) authentication cache (user docs cache)
[ https://issues.apache.org/jira/browse/COUCHDB-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882237#action_12882237 ] Chris Anderson commented on COUCHDB-807: the users_db test is still failing for me: # Assertion failed: e.error == "unauthorized" # Assertion failed: /conflict/.test(e.reason) Is this related to this patch? Do we need to finish applying it? Chris > authentication cache (user docs cache) > -- > > Key: COUCHDB-807 > URL: https://issues.apache.org/jira/browse/COUCHDB-807 > Project: CouchDB > Issue Type: Improvement > Environment: trunk >Reporter: Filipe Manana >Assignee: Filipe Manana > Fix For: 1.0 > > Attachments: auth_cache.patch, auth_cache_2.patch > > > Currently, in order to authenticate an incoming request, each authentication > handler will read a user doc from the _users DB. > By default, 3 authentication handlers are defined (default.ini), which means > we can have 3 _users DB lookups (besides 3 DB open and close operations). > Taking into account that this is done for each incoming HTTP request, for > very busy servers this current behaviour might be overkill. > The following patch adds a new gen_server which implements an authentication > cache and keeps the _users DB open all the time, so that cache misses and > refreshes are as quick as possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-792) Bespin integrated in Futon views editor
[
https://issues.apache.org/jira/browse/COUCHDB-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882224#action_12882224
]
Chris Anderson commented on COUCHDB-792:
I'm gonna hold off on reviewing this until after 1.0 is out. We don't want to
make such a big change just before 1.0 anyway. With all the work that is going
into Bespin these dats, I expect this patch (or something like it) will be
viable in the next few months.
> Bespin integrated in Futon views editor
> ---
>
> Key: COUCHDB-792
> URL: https://issues.apache.org/jira/browse/COUCHDB-792
> Project: CouchDB
> Issue Type: New Feature
> Components: Futon
> Environment: HTML5 / Javascript
>Reporter: Mickael Bailly
>Priority: Minor
> Fix For: 0.11.1
>
> Attachments: futon-bespin.patch.gz
>
>
> Here is the "less-intrusive-I-can" patch to enable bespin editor in Futon
> database views page.
> Implementation constraints :
> - bespin can't have multiple instances
> - bespin can't be enabled=>disabled=>enabled
> I also met a bug on Google Chrome because CouchDB doesn't set a charset in
> HTTP response headers for database.html ... As a result I only succeded with
> BespinEmbedded 0.7.1.
> Implementation details :
> - created proxy functions to get and set map/reduce code to/from editor (
> instead of $("#viewcode_map").val() ... )
> - created bespin wrapper class
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-759) rewriter should be securely jailed in a single database by default
[ https://issues.apache.org/jira/browse/COUCHDB-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-759. -- Resolution: Fixed fixed in r941451 > rewriter should be securely jailed in a single database by default > -- > > Key: COUCHDB-759 > URL: https://issues.apache.org/jira/browse/COUCHDB-759 > Project: CouchDB > Issue Type: Bug >Reporter: Chris Anderson > > This will allow us to isolate databases using vhosts and the browser's > single-origin policy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-719) Bad escaping in Futon view document list
[ https://issues.apache.org/jira/browse/COUCHDB-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-719. -- Resolution: Fixed fixed in COUCHDB-748 > Bad escaping in Futon view document list > > > Key: COUCHDB-719 > URL: https://issues.apache.org/jira/browse/COUCHDB-719 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 0.11 >Reporter: Dirkjan Ochtman >Priority: Minor > Fix For: 0.11.1 > > Attachments: > 0001-Fixes-COUCHDB-719-Bad-escaping-in-Futon-view-documen.patch > > > I have a database where document ID's include '<' and '>'. When I browse the > database, Futon shows '<' for the key (double-escaping the actual value). > On the other hand, for the ID just below that, the entire value is missing, > suggesting that it's not escaped at all in that case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-748) Keys and document IDs are improperly escaped in document list
[ https://issues.apache.org/jira/browse/COUCHDB-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-748. -- Resolution: Fixed thanks. applied in r957622 > Keys and document IDs are improperly escaped in document list > - > > Key: COUCHDB-748 > URL: https://issues.apache.org/jira/browse/COUCHDB-748 > Project: CouchDB > Issue Type: Bug > Components: Futon >Reporter: Paul Bonser >Priority: Minor > Attachments: escape_id.patch > > > In the Futon document list, as generated by > $.futon.CouchDatabasePage.updateDocumentListing, "<", ">", and "&" are > double-encoded for row keys and left unencoded for document IDs. > Also, Firefox (maybe other browsers) seems to get confused when there are > single-quotes inside a URL, so it seems they need to be escaped, too. > The double-encoding is caused by the fact that the jQuery text() function > encodes those characters when they were already encoded by > $.futon.formatJson, and the lack of encoding is caused by simply using the > raw id. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-742) the link in Futon "Welcome !" is not proxy aware
[ https://issues.apache.org/jira/browse/COUCHDB-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-742. -- Resolution: Fixed thanks for reporting. fixed in r957619 > the link in Futon "Welcome !" is not proxy aware > --- > > Key: COUCHDB-742 > URL: https://issues.apache.org/jira/browse/COUCHDB-742 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 0.11 > Environment: ubuntu 9.10 (self compiled couchdb) >Reporter: Damjan Georgievski > > I'm running CouchDB behind a nginx proxy, under a separate path /couch > After the issue #321 has been closed mostly Futon seems to work, except the > link under "Welcome !" (right bottom corner of Futon after you > create an admin user). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-741) incompete error message when creating database with invalid name
[
https://issues.apache.org/jira/browse/COUCHDB-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-741.
--
Resolution: Fixed
applied in r957613. thanks!
> incompete error message when creating database with invalid name
>
>
> Key: COUCHDB-741
> URL: https://issues.apache.org/jira/browse/COUCHDB-741
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core, Documentation
>Affects Versions: 0.11
>Reporter: Andrew Alexander
>Priority: Trivial
> Attachments: COUCHDB-741.patch
>
>
> The illegal_database_name reason fails to specify all the requirements,
> causing it to be misleading. See example below. (failed to begin with a
> letter)
> x...@dev:$ restclient http://127.0.0.1:5984/4df57220060c10afb9aad04dec097388
> {
> "error": "illegal_database_name",
> "reason": "Only lowercase characters (a-z), digits (0-9), and any of the
> characters _, $, (, ), +, -, and / are allowed"
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-795) Allow broken HTTP clients to fake a full method vocabulary with an X-HTTP-METHOD-OVERRIDE header
[ https://issues.apache.org/jira/browse/COUCHDB-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-795. -- Resolution: Fixed applied in 957610. Thanks! > Allow broken HTTP clients to fake a full method vocabulary with an > X-HTTP-METHOD-OVERRIDE header > > > Key: COUCHDB-795 > URL: https://issues.apache.org/jira/browse/COUCHDB-795 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface >Reporter: Brian Jenkins >Priority: Minor > Fix For: 0.11.1 > > Attachments: couchdiff > > > Some older HTTP clients can't issue all HTTP methods. > A common work-around is to POST a request with the X-HTTP-METHOD-OVERRIDE > header set to the desired method. > A patch is attached which adds this facility to couchdb. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-809) Saving an attachment stub with a missing revpos field results in a 412 Precondition Failed (missing_stub) error
[
https://issues.apache.org/jira/browse/COUCHDB-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882204#action_12882204
]
Chris Anderson commented on COUCHDB-809:
That looks pretty solid, but it's important to have tests for this stuff as
otherwise there's nothing to keep it from breaking again. Are you comfortable
adding a test case to the attachments.js test in Futon?
> Saving an attachment stub with a missing revpos field results in a 412
> Precondition Failed (missing_stub) error
> ---
>
> Key: COUCHDB-809
> URL: https://issues.apache.org/jira/browse/COUCHDB-809
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.11
> Environment: Mac OS X 10.6, CouchDBX 0.11.0
>Reporter: Caleb Land
>
> If you PUT a document with attachment stubs that are missing the revpos
> field, a 412 Precondition Failed error is raised with the message:
> {"error":"missing_stub","reason":"id:test, name:graph.html"}
> If a revpos is provided, then everything works ok.
> Here is some sample ruby code that demonstrates this:
> http://gist.github.com/450323
> I think the only field that should be required for an attachment is the
> "stub" field.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-802) Doc ID should auto-generate if not provided, before sending to _update function [PATCH]
[
https://issues.apache.org/jira/browse/COUCHDB-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-802.
--
Resolution: Fixed
applied in r955389
Thanks everyone. I changed the patch slightly on the way in, so it adds a
req.uuid to every request. This way the "hello" test isn't busted.
> Doc ID should auto-generate if not provided, before sending to _update
> function [PATCH]
> ---
>
> Key: COUCHDB-802
> URL: https://issues.apache.org/jira/browse/COUCHDB-802
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface, JavaScript View Server
>Affects Versions: 0.11
> Environment: Linux
>Reporter: Jason Smith
>Priority: Minor
> Fix For: 0.11.1
>
> Attachments: COUCHDB-802-with-test.diff,
> COUCHDB-802-with-test_take2.diff, COUCHDB-802-with-test_take3.diff,
> new_id.diff
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> The main bug is this: _show and _update functions should be able to mimic the
> standard HTTP/JSON API. A common pattern people are moving to is rewriting to
> _show and _update, so the client thinks it is hitting normal couch, however
> additional logic happens (e.g. auto-timestamping).
> Unfortunately, _update cannot return an auto-generated ID for POST to
> /db/_design/ddoc/_update. The semantics should match POST to /db/ -- If an
> _id is provided, use that; otherwise auto-generate one. The best an _update
> function can do now is Math.random() or similar; however one loses the
> advantage of sequential UUID generation from couch's internals.
> The fix is for couch to send a random UUID if the update URL did not include
> the final /Id component. The function itself in the view server can decide
> whether to use it. Assuming that change, the update function could at least
> be capable of duplicating the direct API using the following Javascript logic:
> function(doc, req) {
> if(doc && doc._id == req.id) {
> // To be pedantic, I could confirm req.method == "PUT"
> log("I am an update by id");
> } else if(doc === null && req.id) {
> if(req.method == "POST") {
> log("I am a create, id was auto-generated");
> } else if(req.method == "PUT") {
> log("I am a create, id was supplied by client");
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-802) Doc ID should auto-generate if not provided, before sending to _update function [PATCH]
[
https://issues.apache.org/jira/browse/COUCHDB-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879367#action_12879367
]
Chris Anderson commented on COUCHDB-802:
If anyone can add a test case I'll commit it. I can't promise I've got time to
add the test case myself. Should be a small JS test patch.
> Doc ID should auto-generate if not provided, before sending to _update
> function [PATCH]
> ---
>
> Key: COUCHDB-802
> URL: https://issues.apache.org/jira/browse/COUCHDB-802
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface, JavaScript View Server
>Affects Versions: 0.11
> Environment: Linux
>Reporter: Jason Smith
>Priority: Minor
> Fix For: 0.11.1
>
> Attachments: new_id.diff
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> The main bug is this: _show and _update functions should be able to mimic the
> standard HTTP/JSON API. A common pattern people are moving to is rewriting to
> _show and _update, so the client thinks it is hitting normal couch, however
> additional logic happens (e.g. auto-timestamping).
> Unfortunately, _update cannot return an auto-generated ID for POST to
> /db/_design/ddoc/_update. The semantics should match POST to /db/ -- If an
> _id is provided, use that; otherwise auto-generate one. The best an _update
> function can do now is Math.random() or similar; however one loses the
> advantage of sequential UUID generation from couch's internals.
> The fix is for couch to send a random UUID if the update URL did not include
> the final /Id component. The function itself in the view server can decide
> whether to use it. Assuming that change, the update function could at least
> be capable of duplicating the direct API using the following Javascript logic:
> function(doc, req) {
> if(doc && doc._id == req.id) {
> // To be pedantic, I could confirm req.method == "PUT"
> log("I am an update by id");
> } else if(doc === null && req.id) {
> if(req.method == "POST") {
> log("I am a create, id was auto-generated");
> } else if(req.method == "PUT") {
> log("I am a create, id was supplied by client");
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-791) Changes not written if server shutdown during delayed_commits period
[
https://issues.apache.org/jira/browse/COUCHDB-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878678#action_12878678
]
Chris Anderson commented on COUCHDB-791:
Randall,
That's not a bad idea.
Apache CouchDB has started. Time to relax.
Notice: You should configure delayed_commits=false for better durability.
delayed_commits=true is faster for a single user, but doesn't have a
performance benefit under concurrent load. More info:
http://wiki.apache.org/page/about/delayed_commit
Something like this ^
> Changes not written if server shutdown during delayed_commits period
>
>
> Key: COUCHDB-791
> URL: https://issues.apache.org/jira/browse/COUCHDB-791
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.11.1
> Environment: Linux (Ubuntu 10.04)
>Reporter: Matt Goodall
>
> If the couchdb server is shutdown (couchdb -d, Ctrl+C at the console, etc)
> during the delayed commits period then buffered updates are lost.
> Simple script to demonstrate the problem is:
> db=http://localhost:5984/scratch
> curl $db -X DELETE
> curl $db -X PUT
> curl $db -X POST -d '{}'
> /path/to/couchdb/bin/couchdb -d
> When couchdb is started again the database is empty.
> Affects 0.11.x and trunk branches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-791) Changes not written if server shutdown during delayed_commits period
[
https://issues.apache.org/jira/browse/COUCHDB-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878662#action_12878662
]
Chris Anderson commented on COUCHDB-791:
or
1) flip delayed_commits to false
2) sleep for 2 seconds (1 second is the commit delay)
3) kill the pid
I think this does it. I could be wrong
> Changes not written if server shutdown during delayed_commits period
>
>
> Key: COUCHDB-791
> URL: https://issues.apache.org/jira/browse/COUCHDB-791
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.11.1
> Environment: Linux (Ubuntu 10.04)
>Reporter: Matt Goodall
>
> If the couchdb server is shutdown (couchdb -d, Ctrl+C at the console, etc)
> during the delayed commits period then buffered updates are lost.
> Simple script to demonstrate the problem is:
> db=http://localhost:5984/scratch
> curl $db -X DELETE
> curl $db -X PUT
> curl $db -X POST -d '{}'
> /path/to/couchdb/bin/couchdb -d
> When couchdb is started again the database is empty.
> Affects 0.11.x and trunk branches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-791) Changes not written if server shutdown during delayed_commits period
[
https://issues.apache.org/jira/browse/COUCHDB-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878645#action_12878645
]
Chris Anderson commented on COUCHDB-791:
but wouldn't option 1 do the trick? assuming there isn't a crash just after
`couchdb -d` is invoked.
> Changes not written if server shutdown during delayed_commits period
>
>
> Key: COUCHDB-791
> URL: https://issues.apache.org/jira/browse/COUCHDB-791
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.11.1
> Environment: Linux (Ubuntu 10.04)
>Reporter: Matt Goodall
>
> If the couchdb server is shutdown (couchdb -d, Ctrl+C at the console, etc)
> during the delayed commits period then buffered updates are lost.
> Simple script to demonstrate the problem is:
> db=http://localhost:5984/scratch
> curl $db -X DELETE
> curl $db -X PUT
> curl $db -X POST -d '{}'
> /path/to/couchdb/bin/couchdb -d
> When couchdb is started again the database is empty.
> Affects 0.11.x and trunk branches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-796) Bignum support
[ https://issues.apache.org/jira/browse/COUCHDB-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878643#action_12878643 ] Chris Anderson commented on COUCHDB-796: +1 on repatching mochijson2 -1 on magic-string numbers if you need super-precise bignums, you're gonna have to run a query server that supports them. might I suggest Erlang views? > Bignum support > -- > > Key: COUCHDB-796 > URL: https://issues.apache.org/jira/browse/COUCHDB-796 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Affects Versions: 0.11 >Reporter: Robert Newson > Fix For: 1.0 > > > CouchDB uses spidermonkey which can only handle 32 bit integer values before > overflowing. This might surprise users of map/reduce on large datasets. > Instead, alter mochijson2.erl to handle bignums and encode numeric values as > strings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-791) Changes not written if server shutdown during delayed_commits period
[
https://issues.apache.org/jira/browse/COUCHDB-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878639#action_12878639
]
Chris Anderson commented on COUCHDB-791:
On IRC we discussed this and came up with 2 robust options:
1 is to have `couchdb -d` configure the server to delayed_commits=false for a
few seconds before shutdown
2 is to call an os level `sync` command after shutdown, to ensure that anything
written but not flushed, is flushed.
I don't know enough about 2, but if it is actually robust, it might be simpler
than 1.
> Changes not written if server shutdown during delayed_commits period
>
>
> Key: COUCHDB-791
> URL: https://issues.apache.org/jira/browse/COUCHDB-791
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.11.1
> Environment: Linux (Ubuntu 10.04)
>Reporter: Matt Goodall
>
> If the couchdb server is shutdown (couchdb -d, Ctrl+C at the console, etc)
> during the delayed commits period then buffered updates are lost.
> Simple script to demonstrate the problem is:
> db=http://localhost:5984/scratch
> curl $db -X DELETE
> curl $db -X PUT
> curl $db -X POST -d '{}'
> /path/to/couchdb/bin/couchdb -d
> When couchdb is started again the database is empty.
> Affects 0.11.x and trunk branches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-791) Changes not written if server shutdown during delayed_commits period
[
https://issues.apache.org/jira/browse/COUCHDB-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877426#action_12877426
]
Chris Anderson commented on COUCHDB-791:
We even have a test that the last second of updates are lost here:
http://svn.apache.org/repos/asf/couchdb/trunk/share/www/script/test/delayed_commits.js
I'm wary of introducing the concept of a normal shutdown. How often do you
shutdown a live server? I'm guessing it's something you have never done.
Servers go down because they run out of memory, or get struck by lightning.
Outside of your test scenario, it is hard to see when a server under load would
ever be shutdown cleanly. Which is why it doesn't make sense to have a clean
shutdown mode.
It is trivial to configure couchdb to force a commit for every write, and as I
mentioned before, under concurrent load, it is much faster. Under single user
load it is dog slow (10-ish writes per second) which is why we ship with
delayed_commits on by default.
I think couchdb -d is just a shell script, so if it called /_ensure_full_commit
before it kills the pid, that'd be OK. But core CouchDB shouldn't have shutdown
code in it.
> Changes not written if server shutdown during delayed_commits period
>
>
> Key: COUCHDB-791
> URL: https://issues.apache.org/jira/browse/COUCHDB-791
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.11.1
> Environment: Linux (Ubuntu 10.04)
>Reporter: Matt Goodall
>
> If the couchdb server is shutdown (couchdb -d, Ctrl+C at the console, etc)
> during the delayed commits period then buffered updates are lost.
> Simple script to demonstrate the problem is:
> db=http://localhost:5984/scratch
> curl $db -X DELETE
> curl $db -X PUT
> curl $db -X POST -d '{}'
> /path/to/couchdb/bin/couchdb -d
> When couchdb is started again the database is empty.
> Affects 0.11.x and trunk branches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-791) Changes not written if server shutdown during delayed_commits period
[
https://issues.apache.org/jira/browse/COUCHDB-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877415#action_12877415
]
Chris Anderson commented on COUCHDB-791:
This is the expected behavior. To avoid this, turn delayed_commits off.
In my experience CouchDB has higher throughput under concurrent load without
delayed_commits, so they are really only a performance aid in the single-user
or naive-benchmark use case.
> Changes not written if server shutdown during delayed_commits period
>
>
> Key: COUCHDB-791
> URL: https://issues.apache.org/jira/browse/COUCHDB-791
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.11.1
> Environment: Linux (Ubuntu 10.04)
>Reporter: Matt Goodall
>
> If the couchdb server is shutdown (couchdb -d, Ctrl+C at the console, etc)
> during the delayed commits period then buffered updates are lost.
> Simple script to demonstrate the problem is:
> db=http://localhost:5984/scratch
> curl $db -X DELETE
> curl $db -X PUT
> curl $db -X POST -d '{}'
> /path/to/couchdb/bin/couchdb -d
> When couchdb is started again the database is empty.
> Affects 0.11.x and trunk branches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-791) Changes not written if server shutdown during delayed_commits period
[
https://issues.apache.org/jira/browse/COUCHDB-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-791.
--
Resolution: Not A Problem
> Changes not written if server shutdown during delayed_commits period
>
>
> Key: COUCHDB-791
> URL: https://issues.apache.org/jira/browse/COUCHDB-791
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.11.1
> Environment: Linux (Ubuntu 10.04)
>Reporter: Matt Goodall
>
> If the couchdb server is shutdown (couchdb -d, Ctrl+C at the console, etc)
> during the delayed commits period then buffered updates are lost.
> Simple script to demonstrate the problem is:
> db=http://localhost:5984/scratch
> curl $db -X DELETE
> curl $db -X PUT
> curl $db -X POST -d '{}'
> /path/to/couchdb/bin/couchdb -d
> When couchdb is started again the database is empty.
> Affects 0.11.x and trunk branches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-686) Improve ordering of replication
[ https://issues.apache.org/jira/browse/COUCHDB-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-686. -- Resolution: Not A Problem > Improve ordering of replication > --- > > Key: COUCHDB-686 > URL: https://issues.apache.org/jira/browse/COUCHDB-686 > Project: CouchDB > Issue Type: Improvement > Components: Replication >Affects Versions: 0.10.1 >Reporter: Dirkjan Ochtman >Priority: Minor > Fix For: 0.12 > > > Currently, (continuous) replication almost preserves the ordering of the > updates. It would be nice if this could be fixed so that the order of > outgoing updates fully corresponds to the order inside the source database. > While this may fall down in some clustering situations, it's a great > guarantee to provide in many smaller situations involving an ordered stream > of documents/updates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-773) parse_view_params does not store stale option in record
[ https://issues.apache.org/jira/browse/COUCHDB-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869769#action_12869769 ] Chris Anderson commented on COUCHDB-773: I think it's OK as it is, b/c the only place the stale arg is used is in couch_httpd_view, which uses get_stale_type(Req) to parse the args. > parse_view_params does not store stale option in record > --- > > Key: COUCHDB-773 > URL: https://issues.apache.org/jira/browse/COUCHDB-773 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.12 >Reporter: Volker Mische >Priority: Minor > Fix For: 1.0 > > Attachments: queryargs_stale.diff > > > parse_view_params/3 in couch_httpd_view parses the "stale" query parameter, > but it's not stored in the view_query_args record. I'm not sure if it is a > bug or intention. Please enlighten me. Nonethelsess I've attached a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-759) rewriter should be securely jailed in a single database by default
rewriter should be securely jailed in a single database by default -- Key: COUCHDB-759 URL: https://issues.apache.org/jira/browse/COUCHDB-759 Project: CouchDB Issue Type: Bug Reporter: Chris Anderson This will allow us to isolate databases using vhosts and the browser's single-origin policy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-751) [patch] to add ability to do a list function GET / POST to jquery.couch.js
[
https://issues.apache.org/jira/browse/COUCHDB-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-751.
--
Resolution: Fixed
thanks for the patch! applied in r939443
> [patch] to add ability to do a list function GET / POST to jquery.couch.js
> --
>
> Key: COUCHDB-751
> URL: https://issues.apache.org/jira/browse/COUCHDB-751
> Project: CouchDB
> Issue Type: Improvement
>Affects Versions: 0.11
>Reporter: Jarrod Roberson
>Priority: Trivial
> Attachments: jquery.couch.js
>
>
> I added a list function query support to jquery.couch.js.
> list: function(list, view, options) {
> var list = list.split('/');
> var options = options || {};
> var type = 'GET';
> var data = null;
> if (options['keys']) {
> type = 'POST';
> var keys = options['keys'];
> delete options['keys'];
> data = toJSON({'keys': keys });
> }
> ajax({
> type: type,
> data: data,
> url: this.uri + '_design/' + list[0] +
>'/_list/' + list[1] + '/' + view + encodeOptions(options)
> },
> options, 'An error occured accessing the list'
> );
> },
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-749) CouchDB does not persist large values of Numbers correctly.
[
https://issues.apache.org/jira/browse/COUCHDB-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860711#action_12860711
]
Chris Anderson commented on COUCHDB-749:
Since we are only concerned with storage and round-trip, it doesn't matter
about Erlang arithmetic.
I think we should patch our JSON parser to handle arbitrary ints again.
We should clearly document that the view server doesn't have the same integer
guarantees as the storage engine. I don't agree that we should adopt
spidermonkey's limitations. The JSON spec is very clear on the fact that a
valid JSON implementation may support only very small numbers. (Eg you can
round everything to 0 and still be valid JSON.) That's no reason for us to act
that way.
> CouchDB does not persist large values of Numbers correctly.
> ---
>
> Key: COUCHDB-749
> URL: https://issues.apache.org/jira/browse/COUCHDB-749
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.11
> Environment: All
>Reporter: Jarrod Roberson
>
> All the following operations exhibit the same bug, large numbers don't get
> persisted correctly. They get something added to them for some reason.
> 9223372036854775807 == java.lang.Long.MAX_VALUE
> 1: go into Futon, create a new document and create a new field and enter the
> number 9223372036854775807, click the green check mark, the number changes to
> 9223372036854776000 even before you save it.
> 2.curl -X PUT http://localhost:5984/test/longTest -d '{"value":
> 9223372036854775807}', the number gets persisted as 9223372036854776000
> trying to persist System.currentTimeMilliseconds() from java causes the same
> thing to happen occasionally.
> This seems to be a pretty serious bug if I can't trust that my data is not
> being corrupted when submitted to the database.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-740) Fix Erlang view server when calling a filter function
[
https://issues.apache.org/jira/browse/COUCHDB-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-740.
--
Resolution: Fixed
closed in 936889
thanks for the patch!
> Fix Erlang view server when calling a filter function
> -
>
> Key: COUCHDB-740
> URL: https://issues.apache.org/jira/browse/COUCHDB-740
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.11
>Reporter: Filipe Manana
> Attachments: erlang-view-server-filter-function-fix-3.patch
>
>
> Reported to the dev mailing list by Ivan Bodunov:
> "Hi,
> After I wrote my filter in JavaScript I decided to rewrite it in Erlang and
> faced some problems.
> Even the simplest possible filter written in Erlang causes crashes in
> CouchDB.
> Filter is
>"filters": { "foo": "fun({Doc},Req) -> true end." }
> Command to trigger the filter is
># curl -X GET http://localhost:5984/mytemp/_changes?filter=erl/foo
> Following link contains the crash report:
> http://friendpaste.com/6eFpPOtTaaSRiXEvaUEmrZ
> CouchDB 0.11 on Mac.
> "
> patch attached with test
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-739) Upgrade CommonJS modules support to Modules/1.1.1
[ https://issues.apache.org/jira/browse/COUCHDB-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-739. -- Resolution: Fixed applied in r934652 > Upgrade CommonJS modules support to Modules/1.1.1 > - > > Key: COUCHDB-739 > URL: https://issues.apache.org/jira/browse/COUCHDB-739 > Project: CouchDB > Issue Type: Improvement > Components: JavaScript View Server >Reporter: mikeal > Attachments: modules.diff > > > Our current commonjs modules support is based version 1.0 of the Modules > specification. Modules/1.1 had some points that made it difficult and/or > impossible for us to implement to spec so I worked with the commonjs guys on > an upgraded revion, 1.1.1, which we are able to implement. > http://wiki.commonjs.org/wiki/Modules/1.1.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COUCHDB-736) stale-ok view queries can return inconsistent partial results
stale-ok view queries can return inconsistent partial results - Key: COUCHDB-736 URL: https://issues.apache.org/jira/browse/COUCHDB-736 Project: CouchDB Issue Type: Bug Affects Versions: 0.11 Reporter: Chris Anderson since r796805 requests to views with the stale=ok option have returned partially computed index results. This changed the semantics of views. This ticket is about maintaining the old semantics. This should be changed so stale=ok only returns what would be returned by a normal view request. stale=partial would be an OK name for an option to provide the current behavior. The best way to fix this would be to store the NewGroup sent on the partial_update cast in #group_state.partial_group instead of #group_state.group This will also eliminate the (rare) changes of serving inconsistent results with a regular view query. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (COUCHDB-658) Add CommonJS style modules to the view server
[ https://issues.apache.org/jira/browse/COUCHDB-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson resolved COUCHDB-658. Fix Version/s: 0.11 Resolution: Fixed this was resolved before 0.11 > Add CommonJS style modules to the view server > - > > Key: COUCHDB-658 > URL: https://issues.apache.org/jira/browse/COUCHDB-658 > Project: CouchDB > Issue Type: Improvement > Components: JavaScript View Server > Environment: CouchDB >Reporter: mikeal > Fix For: 0.11 > > Attachments: require.patch > > > I have a patch that adds CommonJS module support to all ddoc aware view > server functions (everything except map/reduce/rereduce). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (COUCHDB-693) require function - add support for requiring plain html/xml files in addition to only javascript
[
https://issues.apache.org/jira/browse/COUCHDB-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson resolved COUCHDB-693.
Resolution: Fixed
Thanks for the report.
Sorry I didn't see it earlier. The proper way to do this in _show _list etc
function (where require is available, is to use 'this' which refers to the
design document. So you can load templates like:
function(doc, req) {
var template = this.templates.entry;
var Mustache = require("lib/mustache");
return Mustache.to_html(template, doc);
}
For more examples see Sofa:
http://github.com/jchris/sofa/blob/master/shows/edit.js
Chris
> require function - add support for requiring plain html/xml files in addition
> to only javascript
>
>
> Key: COUCHDB-693
> URL: https://issues.apache.org/jira/browse/COUCHDB-693
> Project: CouchDB
> Issue Type: Improvement
>Affects Versions: 0.11
> Environment: MacOS X 10.6.2
>Reporter: Marcos Zanona
>Priority: Trivial
>
> It seems that for now every require function on the main.js it is created an
> empty exports object which is returned after the call.
> I would suggest that instead of creating one empty exports object:
> --
> var require = function(name, parent) {
> var exports = {};
> var resolved = resolveModule(name.split('/'), parent, ddoc);
> var source = resolved[0];
> parent = resolved[1];
> ...
> ---
> that one pre-populated object could be created:
> ---
> var require = function(name, parent) {
> var resolved = resolveModule(name.split('/'), parent, ddoc);
> var source = resolved[0];
> var exports = {"source" : source}; /* <-- this would populate
> the exports with an embedded source */
> parent = resolved[1];
> --
> this done, users would be able to require plain plain html/xml files directly
> without need to declare any javascript variable or exports...
> this is very nice for templating specifically because javascript support xml
> syntax without any problem and also it's possible declare javascript
> variables inside the xml like Hello there, {name}
> so it would be possible to require something like this
> templates/master.html -->
>
>
> title
>
>
> That's my content
>
>
>
> and then simply require it using:
> var template = require("templates/master.html");
> send(template.source);
> ---
> I'm still trying to adjust it to be possible for user to just user plain text
> files without quotes which would increase the possibilities for users to
> create their own view engines such as HAML and SASS.
> In case the user is using just regular javascript he can easily overwrite the
> source variable with exports.source ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (COUCHDB-705) hard limit on number of concurrent requests
[ https://issues.apache.org/jira/browse/COUCHDB-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson resolved COUCHDB-705. Resolution: Fixed applied in r931663 > hard limit on number of concurrent requests > --- > > Key: COUCHDB-705 > URL: https://issues.apache.org/jira/browse/COUCHDB-705 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 0.11 > Environment: all >Reporter: Randall Leeds >Priority: Minor > Attachments: mochiweb_max_connections.patch > > > mochiweb has a default maximum number of concurrent requests set to 2048. For > some deployments this is too small. Many simultaneous replications can easily > exhaust this limit and cause slow responses to client requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-705) hard limit on number of concurrent requests
[
https://issues.apache.org/jira/browse/COUCHDB-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854663#action_12854663
]
Chris Anderson commented on COUCHDB-705:
the only thing I see here is that the line:
MaxConnections = couch_config:get("httpd", "max_connections", 2048),
should instead specify 2048 as "2048" and parse the string to int, as in cases
where it's config'd, I think we'll get a string back.
At least that's how couch deals with numeric config elsewhere.
> hard limit on number of concurrent requests
> ---
>
> Key: COUCHDB-705
> URL: https://issues.apache.org/jira/browse/COUCHDB-705
> Project: CouchDB
> Issue Type: Improvement
>Affects Versions: 0.11
> Environment: all
>Reporter: Randall Leeds
>Priority: Minor
> Attachments: mochiweb_max_connections.patch
>
>
> mochiweb has a default maximum number of concurrent requests set to 2048. For
> some deployments this is too small. Many simultaneous replications can easily
> exhaust this limit and cause slow responses to client requests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COUCHDB-650) Add "now" option for ?since parameter on _changes
[ https://issues.apache.org/jira/browse/COUCHDB-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson resolved COUCHDB-650. Resolution: Fixed This is mostly closed by r931439 (Thanks Joscha) r931439 adds an update_seq JSON member to view responses, making it possible to use _changes to update information loaded via view, without chances of getting multiple updates twice, or missing updates. This doesn't add a ?local_seq=true option to document requests, but if anyone wants to add this, it would be the way to go (similar to the ddoc.options.local_seq = true that can be used to make the doc._local_seq available to the view engine.) > Add "now" option for ?since parameter on _changes > - > > Key: COUCHDB-650 > URL: https://issues.apache.org/jira/browse/COUCHDB-650 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Reporter: Randall Leeds >Priority: Minor > Attachments: > 0001-add-since-now-option-to-continuous-catch-edge-cases-.patch, > update_seq.diff, view_update_seq.js > > > As per a discussion on IRC with mikeal, jan_, whartung, and rnewson: > Having _changes?since="now" allows clients to listen to only new changes > without making two requests (one to extract seq from /db, and one _changes). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-628) add dates to releases on website download page
[ https://issues.apache.org/jira/browse/COUCHDB-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854163#action_12854163 ] Chris Anderson commented on COUCHDB-628: +1 I was just wishing for this in the NEWS and CHANGES files myself. > add dates to releases on website download page > -- > > Key: COUCHDB-628 > URL: https://issues.apache.org/jira/browse/COUCHDB-628 > Project: CouchDB > Issue Type: Improvement > Components: Build System >Reporter: Don Park >Assignee: Noah Slater > > it may seem like a small deal but its very handy to have the date of the > release listed along with the version of couchdb on the download page. > http://couchdb.apache.org/downloads.html > thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-709) Restart actually restarts the server
[ https://issues.apache.org/jira/browse/COUCHDB-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-709. -- Resolution: Fixed > Restart actually restarts the server > > > Key: COUCHDB-709 > URL: https://issues.apache.org/jira/browse/COUCHDB-709 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Reporter: Chris Anderson > > This patch will cause CouchDB to actually restart the server when a POST is > made to /_restart > The old way was unreliable as supervisors would shut things down > asynchronously. This new way is much more brute force, which makes it more > deterministic. > This only really effects the test suite. I'm only pushing the patch through > Jira to see if people see room for improvements. > One improvement would be to add a timestamp for server boot time to the / > response, but I seem to have avoided the need for that with my double GET > magic. > Do note: restart now drops any temporary config, hence the change to the > reader_acls test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-707) Proposal for "Filter Views"
[ https://issues.apache.org/jira/browse/COUCHDB-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851223#action_12851223 ] Chris Anderson commented on COUCHDB-707: The forced deleting of remote documents for just some users isn't currently supported (and isn't really compatible with offline data.) I'd be be happy to support include_doc lookups for JSON list responses. It's a fair amount of code, so I'd expect whoever will be using it to write it. If you do create this feature, I'm happy to commit it, but I want to note my architectural reservations here. > Proposal for "Filter Views" > --- > > Key: COUCHDB-707 > URL: https://issues.apache.org/jira/browse/COUCHDB-707 > Project: CouchDB > Issue Type: New Feature > Components: JavaScript View Server >Affects Versions: 0.11 >Reporter: Luke Burton > > A common operation I find myself performing repeatedly is: > * request a view (maybe with some basic filter like "keys" or a range of keys) > * in my client, filter this view based on some complex criteria, leaving me > with a small set of document IDs (complex as in array intersections, compound > boolean operations, & other stuff not possible in the HTTP view API) > * go back to Couch and fetch the complete documents for these IDs. > List Views almost get me to the point of doing this purely in Couch. I can > enumerate over a view and do some complex things with it. But I can't output > entire documents, unless I use the include_docs=true flag which murders the > performance of the list view.Apparently because the entire view is fetched > with including docs, THEN passed on to the list view JS. Typically my complex > filter criteria is contained in the view itself, so there is no need to fetch > the entire document until I know I have a match. > In summary, a Filter View would execute some arbitrary JavaScript on each > view row, with access to HTTP request parameters, and return "true" for rows > that match. The output would be a list of IDs for whom the function returned > true. include_docs=true would include the matching documents. > Performance would certainly not be as good as fetching a raw view, but it > would indisputably be better than fetching the entire view over HTTP to a > client, deserializing the JSON, doing some stuff, then making another HTTP > request, and deserializing more JSON. > I looked at the various entry points for list views in the Couch source. > Unfortunately it will take me some time to come up to speed with the source > (if I ever have the time ...), and I hope that what I'm asking for could be a > simple extension to the List Views for someone very familiar with this area. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-707) Proposal for "Filter Views"
[ https://issues.apache.org/jira/browse/COUCHDB-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851189#action_12851189 ] Chris Anderson commented on COUCHDB-707: The _changes filters are what I'd recommend for this process. For the moment, the best way to do what you are asking (with built-in Couch tools) is to use filtered replication to create a database for each set of filter parameters. In many cases this is easiest expressed as a database-per-user with filters used to ensure everyone only sees the data they are allowed to see. Then you would define your views on the filtered databases. What you request here is not insane, but it's essentially asking Couch to do the filter operation (potentially expensively) at each read operation, instead of incrementally allowing low-latency access to the computed dataset. I think using filtered replication is a good tradeoff between disk usage and app responsiveness, and would suggest it instead of a _list operation. > Proposal for "Filter Views" > --- > > Key: COUCHDB-707 > URL: https://issues.apache.org/jira/browse/COUCHDB-707 > Project: CouchDB > Issue Type: New Feature > Components: JavaScript View Server >Affects Versions: 0.11 >Reporter: Luke Burton > > A common operation I find myself performing repeatedly is: > * request a view (maybe with some basic filter like "keys" or a range of keys) > * in my client, filter this view based on some complex criteria, leaving me > with a small set of document IDs (complex as in array intersections, compound > boolean operations, & other stuff not possible in the HTTP view API) > * go back to Couch and fetch the complete documents for these IDs. > List Views almost get me to the point of doing this purely in Couch. I can > enumerate over a view and do some complex things with it. But I can't output > entire documents, unless I use the include_docs=true flag which murders the > performance of the list view.Apparently because the entire view is fetched > with including docs, THEN passed on to the list view JS. Typically my complex > filter criteria is contained in the view itself, so there is no need to fetch > the entire document until I know I have a match. > In summary, a Filter View would execute some arbitrary JavaScript on each > view row, with access to HTTP request parameters, and return "true" for rows > that match. The output would be a list of IDs for whom the function returned > true. include_docs=true would include the matching documents. > Performance would certainly not be as good as fetching a raw view, but it > would indisputably be better than fetching the entire view over HTTP to a > client, deserializing the JSON, doing some stuff, then making another HTTP > request, and deserializing more JSON. > I looked at the various entry points for list views in the Couch source. > Unfortunately it will take me some time to come up to speed with the source > (if I ever have the time ...), and I hope that what I'm asking for could be a > simple extension to the List Views for someone very familiar with this area. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-709) Restart actually restarts the server
[
https://issues.apache.org/jira/browse/COUCHDB-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849558#action_12849558
]
Chris Anderson commented on COUCHDB-709:
ok, Jira seems unable to accept my patch upload. Follows in plaintext.
diff --git a/share/www/script/couch_tests.js b/share/www/script/couch_tests.js
index 85d0706..3978d48 100644
--- a/share/www/script/couch_tests.js
+++ b/share/www/script/couch_tests.js
@@ -149,6 +149,25 @@ function stringFun(fun) {
return string;
}
+function waitForRestart() {
+ var waiting = true;
+ while (waiting) {
+try {
+ CouchDB.request("GET", "/");
+ CouchDB.request("GET", "/");
+ waiting = false;
+} catch(e) {
+ // the request will fail until restart completes
+}
+ }
+};
+
function restartServer() {
- CouchDB.request("POST", "/_restart");
+ var xhr;
+ try {
+CouchDB.request("POST", "/_restart");
+ } catch(e) {
+// this request may sometimes fail
+ }
+ waitForRestart();
}
diff --git a/share/www/script/test/reader_acl.js
b/share/www/script/test/reader_acl.js
index d173d70..a3b6bd8 100644
--- a/share/www/script/test/reader_acl.js
+++ b/share/www/script/test/reader_acl.js
@@ -28,6 +28,7 @@ couchTests.reader_acl = function(debug) {
roles : ["top-secret"]
}, "funnybone");
T(usersDb.save(jchrisUserDoc).ok);
+ usersDb.ensureFullCommit();
T(CouchDB.session().userCtx.name == null);
@@ -41,12 +42,15 @@ couchTests.reader_acl = function(debug) {
names : ["joe","barb"]
}
}).ok);
-
- usersDb.ensureFullCommit();
- // security changes will always commit synchronously
- restartServer();
-
- // can't read it as jchris
+} finally {
+ CouchDB.logout();
+}
+ }
+
+ // split into 2 funs so we can test restart behavior
+ function testFun2() {
+try {
+ // can't read it as jchris b/c he's missing the needed role
T(CouchDB.login("jch...@apache.org", "funnybone").ok);
T(CouchDB.session().userCtx.name == "jch...@apache.org");
@@ -151,7 +155,7 @@ couchTests.reader_acl = function(debug) {
} finally {
CouchDB.logout();
}
- }
+ };
run_on_modified_server(
[{section: "httpd",
@@ -161,4 +165,16 @@ couchTests.reader_acl = function(debug) {
key: "authentication_db", value: "test_suite_users"}],
testFun
);
+
+ // security changes will always commit synchronously
+ restartServer();
+
+ run_on_modified_server(
+[{section: "httpd",
+ key: "authentication_handlers",
+ value: "{couch_httpd_auth, cookie_authentication_handler},
{couch_httpd_auth, default_authentication_handler}"},
+ {section: "couch_httpd_auth",
+ key: "authentication_db", value: "test_suite_users"}],
+testFun2
+ );
}
diff --git a/src/couchdb/couch_server_sup.erl b/src/couchdb/couch_server_sup.erl
index d89e987..da0fbdb 100644
--- a/src/couchdb/couch_server_sup.erl
+++ b/src/couchdb/couch_server_sup.erl
@@ -32,12 +32,7 @@ start_link(IniFiles) ->
end.
restart_core_server() ->
-supervisor:terminate_child(couch_primary_services, couch_server),
-supervisor:terminate_child(couch_secondary_services, stats_aggregator),
-supervisor:terminate_child(couch_secondary_services, stats_collector),
-supervisor:restart_child(couch_primary_services, couch_server),
-supervisor:restart_child(couch_secondary_services, stats_collector),
-supervisor:restart_child(couch_secondary_services, stats_aggregator).
+init:restart().
couch_config_start_link_wrapper(IniFiles, FirstConfigPid) ->
case is_process_alive(FirstConfigPid) of
> Restart actually restarts the server
>
>
> Key: COUCHDB-709
> URL: https://issues.apache.org/jira/browse/COUCHDB-709
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core
>Reporter: Chris Anderson
>
> This patch will cause CouchDB to actually restart the server when a POST is
> made to /_restart
> The old way was unreliable as supervisors would shut things down
> asynchronously. This new way is much more brute force, which makes it more
> deterministic.
> This only really effects the test suite. I'm only pushing the patch through
> Jira to see if people see room for improvements.
> One improvement would be to add a timestamp for server boot time to the /
> response, but I seem to have avoided the need for that with my double GET
> magic.
> Do note: restart now drops any temporary config, hence the change to the
> reader_acls test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-709) Restart actually restarts the server
Restart actually restarts the server Key: COUCHDB-709 URL: https://issues.apache.org/jira/browse/COUCHDB-709 Project: CouchDB Issue Type: Improvement Components: Database Core Reporter: Chris Anderson This patch will cause CouchDB to actually restart the server when a POST is made to /_restart The old way was unreliable as supervisors would shut things down asynchronously. This new way is much more brute force, which makes it more deterministic. This only really effects the test suite. I'm only pushing the patch through Jira to see if people see room for improvements. One improvement would be to add a timestamp for server boot time to the / response, but I seem to have avoided the need for that with my double GET magic. Do note: restart now drops any temporary config, hence the change to the reader_acls test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-702) Why don't use BSON ?
[ https://issues.apache.org/jira/browse/COUCHDB-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-702. -- Resolution: Invalid BSON is a bad idea. It's not a standard and it tried to do odd stuff like have Date and Regex types. JSON is a ubiquitous standard and just as fast as BSON. > Why don't use BSON ? > - > > Key: COUCHDB-702 > URL: https://issues.apache.org/jira/browse/COUCHDB-702 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Reporter: KV > > I don't know a lot about architecture but if that's possible then why not ? > It should improve disk and network performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-686) Improve ordering of replication
[ https://issues.apache.org/jira/browse/COUCHDB-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843665#action_12843665 ] Chris Anderson commented on COUCHDB-686: Randall's suggestion seems the most appropriate here. However, I'd caution against this using such a feature. For the same reasons we don't support multi-document transactions on a single node (b/c they can't be sanely supported on a cluster), supporting ordering guarantees is dangerous. They are essentially a form of multi-document state. Since is is very clear that they can't be supported in a replication mesh with more than 2 peers, I don't think they are so dangerous as that we shouldn't provide Randall's knob. But we should be clear to the people who choose to architect around it, that what they are doing will be limited to the maximum throughput of a single disk. > Improve ordering of replication > --- > > Key: COUCHDB-686 > URL: https://issues.apache.org/jira/browse/COUCHDB-686 > Project: CouchDB > Issue Type: Improvement > Components: Replication >Affects Versions: 0.10.1 >Reporter: Dirkjan Ochtman >Priority: Minor > Fix For: 0.12 > > > Currently, (continuous) replication almost preserves the ordering of the > updates. It would be nice if this could be fixed so that the order of > outgoing updates fully corresponds to the order inside the source database. > While this may fall down in some clustering situations, it's a great > guarantee to provide in many smaller situations involving an ordered stream > of documents/updates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COUCHDB-645) _update: document created with undefined _id
[
https://issues.apache.org/jira/browse/COUCHDB-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson reassigned COUCHDB-645:
--
Assignee: Chris Anderson
> _update: document created with undefined _id
>
>
> Key: COUCHDB-645
> URL: https://issues.apache.org/jira/browse/COUCHDB-645
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.11
> Environment: Linux, CouchDB built from HEAD
>Reporter: Cliff Stanford
>Assignee: Chris Anderson
> Attachments: updates_handler.patch
>
>
> Using an update handler, if a document is returned with { _id : undefined
> }, the document will be created on the database with an undefined _id and
> will henceforth not be accessible to modify or delete although it will show
> up in views.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-684) Futon security dialog overwrites other properties of security doc
[ https://issues.apache.org/jira/browse/COUCHDB-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842364#action_12842364 ] Chris Anderson commented on COUCHDB-684: On IRC I talked with David about getting Futon to treat the _security object as if it were a doc with an _id of "_security". This would make it much easier to edit. It already almost works: http://localhost:5984/_utils/document.html?mydb/_security except Futon tries to POST because it doesn't have an ID. So it'd be an easy fix for Futon (and we can even put doctext on the JSON edit page so we don't lose the benefit of the dialog box) another option would be to add an _id field to the actual JSON response. certainly easier, especially for non-Futon clients, but I'm wary about "faking" the API so much. > Futon security dialog overwrites other properties of security doc > - > > Key: COUCHDB-684 > URL: https://issues.apache.org/jira/browse/COUCHDB-684 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 0.11 > Environment: OSX 10.6 >Reporter: David Goodlad > Attachments: futon_security.patch > > > When the _security document has existing properties other than readers and > admins, Futon's security dialog will overwrite them. If it's agreed this is > undesirable behaviour, I'll see about putting a patch together. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-680) Security on CouchDB set via Futon does not persist after server restart
[ https://issues.apache.org/jira/browse/COUCHDB-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841062#action_12841062 ] Chris Anderson commented on COUCHDB-680: I'm unable to reproduce this (tried a few times on my machine.) The only things I can think of are: A) It's really a Futon issue that's being reported as a DB issue. B) You are restarting CouchDB so quickly after updating the security objects that it doesn't have time to fsync. I've added a call to ensure_full_commit so that PUT to /db/_security will not return until after an fsync. I think this is a fine thing to do as setting the security will happen rarely, and the consequences of losing such an update due to power outage are greater than the consequences of losing a document update. This was added in r918855 and backported to 0.11.x in r918856. Please update to the latest code and try to reproduce. If no one is able to reproduce I will close this issue. Thanks, Chris > Security on CouchDB set via Futon does not persist after server restart > --- > > Key: COUCHDB-680 > URL: https://issues.apache.org/jira/browse/COUCHDB-680 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.10.1 > Environment: CouchDB 0.11.0b915670 on windowsXP >Reporter: Phat Loc > Fix For: 0.11 > > > I can set the security on a database via Futon. However a server reboot wipes > out the setting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-680) Security on CouchDB set via Futon does not persist after server restart
[ https://issues.apache.org/jira/browse/COUCHDB-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840942#action_12840942 ] Chris Anderson commented on COUCHDB-680: Can anyone reproduce this? I don't have Windows handy, but I've never seen anything like this on OS X. How much time are you giving CouchDB after creating the _security object? Are you creating any documents or just immediately restarting? What method are you using for restart? Maybe we should add an ensure_full_commit after the _security update. I'll need to see this reproduced before I can start to fix it. > Security on CouchDB set via Futon does not persist after server restart > --- > > Key: COUCHDB-680 > URL: https://issues.apache.org/jira/browse/COUCHDB-680 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.10.1 > Environment: CouchDB 0.11.0b915670 on windowsXP >Reporter: Phat Loc > Fix For: 0.11 > > > I can set the security on a database via Futon. However a server reboot wipes > out the setting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-673) Filtered replication
[
https://issues.apache.org/jira/browse/COUCHDB-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-673.
--
Resolution: Fixed
committed in r916518
Thanks Filipe!
> Filtered replication
>
>
> Key: COUCHDB-673
> URL: https://issues.apache.org/jira/browse/COUCHDB-673
> Project: CouchDB
> Issue Type: New Feature
> Components: Replication
>Affects Versions: 0.11
> Environment: trunk / 0.11
>Reporter: Filipe Manana
> Attachments: filtered-replication.patch
>
>
> The following patch adds support for filtered replication.
> A replication object can now have 2 more optional fields: "filter" and
> "query_params".
> Example:
> {
> "source" : "sourceDB",
> "target" : "targetDB",
> "filter" : "mydesign/myfilter",
> "query_params" : {
> "param1" : "value",
> "param2" : int_value
> // etc...
> }
> }
> The filter must exist in the source DB, and it's the same type of filter as
> used by the _changes handler. The parameter "query_params" is used for
> adding fields to the req.query object passed as the second parameter to the
> filter function (like the query string parameters passed to _changes).
> The patch also does a refactoring of the _changes handler, allowing that code
> be used not only as an HTTP API but also as an internal API. The replicator
> now uses this internal API, allowing us to avoid copy-pasting code and have
> all the features of _changes available to the replicator.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-549) include_docs=true doesn't honour conflicts=true
[ https://issues.apache.org/jira/browse/COUCHDB-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838618#action_12838618 ] Chris Anderson commented on COUCHDB-549: this is just a failure to push the conflicts=true parameter through to the include docs code. patches welcome. > include_docs=true doesn't honour conflicts=true > --- > > Key: COUCHDB-549 > URL: https://issues.apache.org/jira/browse/COUCHDB-549 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 0.11 >Reporter: Brian Candler >Priority: Minor > > When you read a view and use the option 'include_docs=true' to get the source > document in each result row, the option 'conflicts=true' is not honoured. You > do not see a _conflicts member in the document, even if it is in a > conflicting state. > This feature request could be expanded in a couple of directions: > 1. Make include_docs=true honour *all* options which a straightforward GET > would honour - e.g. revs, revs_info, open_revs. Maybe this would be > straightforward if they shared the same code path and options processing. > 2. It has been suggested that 'conflicts=true' could be the default anyway. > That is, whenever you retrieve a document, you get a _conflicts member if it > is in a conflicting state, without having to ask for it. This would be > unlikely to break things, but would make it less likely that conflicts would > go unnoticed, and it would simplify the API a little. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-639) Make replication profit of attachment compression and improve push replication for large attachments
[ https://issues.apache.org/jira/browse/COUCHDB-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835779#action_12835779 ] Chris Anderson commented on COUCHDB-639: This patch applies cleanly and the tests are passing. I'm also +1 on the feature (and I sure wouldn't mind committing this before 0.11 is tarballed as the code changes are enough that it might make backporting fixes to 0.11 a pain later on.) However, I'm not 100% sure about _bulk_docs_rep. I'm concerned about having a separate endpoint designed for replication (gives the wrong idea to people -- that replication is special. Replication is just another HTTP client.) I'm also concerned about the implementation (does this copy only new attachments, or does it copy all attachments?) I'd like it of Adam or someone else familiar with the replicator could review this patch. (And apply it if you think it is right.) > Make replication profit of attachment compression and improve push > replication for large attachments > > > Key: COUCHDB-639 > URL: https://issues.apache.org/jira/browse/COUCHDB-639 > Project: CouchDB > Issue Type: Improvement > Components: Replication >Affects Versions: 0.11 > Environment: trunk >Reporter: Filipe Manana > Attachments: rep-att-comp-and-multipart-trunk.patch > > > At the moment, for compressed attachments, the replication uncompresses and > then compresses again the attachments. Therefore, a waste of CPU time. > The push replication is also not reliable for very large attachments (500mb + > for example). Currently it sends the attachments in-lined in the respective > JSON doc. Not only this requires too much ram memory, it also wastes too much > CPU time doing the base64 encoding of the attachment (and also a > decompression if the attachment is compressed). > The following patch (rep-att-comp-and-multipart-trunk*.patch) addresses both > issues. Docs containing attachments are now streamed to the target remote DB > using the multipart doc streaming feature provided by couch_doc.erl, and > compressed attachments are not uncompressed and re-compressed during the > replication > JavaScript tests included. > Previously doing a replication of a DB containing 2 docs with attachments of > 100mb and 500mb caused the Erlang VM to consume near 1.2GB of ram memory in > my system. With that patch applied, it uses about 130Mb of ram memory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-646) JSON object hidden from the sandbox for show and list
[
https://issues.apache.org/jira/browse/COUCHDB-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835745#action_12835745
]
Chris Anderson commented on COUCHDB-646:
I've committed a change in r911602 to explicitly add the JSON object to the
sandbox. Maybe this will help...maybe not.
Cliff do you mind checking to see if JSON.stringify is more useful now?
> JSON object hidden from the sandbox for show and list
> -
>
> Key: COUCHDB-646
> URL: https://issues.apache.org/jira/browse/COUCHDB-646
> Project: CouchDB
> Issue Type: Bug
> Components: Build System
>Affects Versions: 0.11
> Environment: CouchDB built from head. Ubuntu. JavaScript-C 1.7.0
> 2007-10-03
>Reporter: Cliff Stanford
>
> Three issues that I think are related so I have opened them as a single
> ticket.
> TheJSON object defined in main.js appears not to be available any more in
> show and list. I believe it was in a previous release.
> The form object.toJSON() does not seem to be working in show and list.
> var d = new Date(); toJSON(d) returns {} rather than a string. This also
> seems to be affecting views.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
