[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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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_5k.json
Sizes (branch vs trunk):
$ du -m couchdb/tmp/lib/disk_json_test.couch
1996
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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}},
#Funcouch_db_updater.7.69395062,
#Funcouch_db_updater.8.86519079,
#Funcouch_btree.5.124754102,
#Funcouch_db_updater.9.24674233},
{btree,0.116.0,
{97633,500},
#Funcouch_db_updater.10.90337910,
#Funcouch_db_updater.11.13595824,
#Funcouch_btree.5.124754102,
#Funcouch_db_updater.12.34906778},
{btree,0.116.0,nil,
#Funcouch_btree.0.83553141,
#Funcouch_btree.1.30790806,
#Funcouch_btree.2.124754102,nil},
500,test_suite_db,
/usr/local/var/lib/couchdb/test_suite_db.couch,
[],[],nil,
{user_ctx,null,[],undefined},
#Ref0.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}},
#Funcouch_db_updater.7.69395062,
#Funcouch_db_updater.8.86519079,
#Funcouch_btree.5.124754102,
#Funcouch_db_updater.9.24674233},
{btree,0.116.0,
{97633,500},
#Funcouch_db_updater.10.90337910,
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] 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] 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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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] 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] 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] 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-tabpanelfocusedCommentId=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 ] 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-230) Add Support for Rewritable URL
[ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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: 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 davisp 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 davisp bobesponja: or perhaps, regex's - erlang handler davisp 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-tabpanelfocusedCommentId=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: 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 davisp 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 davisp bobesponja: or perhaps, regex's - erlang handler davisp 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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/database.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-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-tabpanelfocusedCommentId=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-832) Handling HTTP OPTIONS method
[ https://issues.apache.org/jira/browse/COUCHDB-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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,
{#Funcouch_httpd_db.5.100501499,
[{httpd,
{mochiweb_request,#Port0.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|
#Funcouch_httpd.8.61263750]],
[],
[[_view_cleanup|
#Funcouch_httpd.8.61263750]],
[],[],[],[],[],
[[_compact|
#Funcouch_httpd.8.61263750]],
[],[],
[[_temp_view|
#Funcouch_httpd.8.61263750]],
[[_changes|
#Funcouch_httpd.8.61263750]],
[],[],[]}}},
{user_ctx,null,
[_admin],
{couch_httpd_auth,
default_authentication_handler}},
undefined,
{dict,6,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],
[],[],[]},
{{[],
[[_show|
#Funcouch_httpd.10.132977763]],
[[_info|
#Funcouch_httpd.10.132977763],
[_list|
#Funcouch_httpd.10.132977763]],
[[_update|
#Funcouch_httpd.10.132977763]],
[],[],[],[],[],
[[_rewrite|
#Funcouch_httpd.10.132977763]],
[],[],[],
[[_view|
#Funcouch_httpd.10.132977763]],
[],[]}}},
undefined,#Funcouch_httpd.6.96187723,
{dict,13,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],
[],[],[]},
{{[[_restart|
#Funcouch_httpd.6.96187723],
[_replicate|
#Funcouch_httpd.6.96187723]],
[jira] Commented: (COUCHDB-53) Incorporating JSearch to CouchDB
[
https://issues.apache.org/jira/browse/COUCHDB-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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] 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] 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-tabpanelfocusedCommentId=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] 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-817) Natively support coffeescript
[ https://issues.apache.org/jira/browse/COUCHDB-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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] 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-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-tabpanelfocusedCommentId=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] Commented: (COUCHDB-161) Range Request support for attachments
[ https://issues.apache.org/jira/browse/COUCHDB-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] Commented: (COUCHDB-776) _replicator DB
[ https://issues.apache.org/jira/browse/COUCHDB-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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] 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] 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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: bitdiddle 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 davisp bitdiddle: you got that far and didn't find it? aquarius davisp: is there a better way to find the port? davisp oh, is that not the bind port? I was just thinking a log statement aquarius 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? davisp aquarius: you have to look at the port returned by the socket aquarius: in other words, CouchDB was never written to do that davisp AFAIK bitdiddle davisp: I found it, just needs some work to expose it davisp aquarius: and by do that, I mean, we never put in a statement to log that bitdiddle mochiweb_http is the module that needs to bubble it up aquarius 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 :) davisp 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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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] 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-742) the link in Futon Welcome username! 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 username! 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 username! (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-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-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 'lt;' 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-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] 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-tabpanelfocusedCommentId=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] Commented: (COUCHDB-807) authentication cache (user docs cache)
[ https://issues.apache.org/jira/browse/COUCHDB-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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] 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] 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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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] 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-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-tabpanelfocusedCommentId=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-796) Bignum support
[ https://issues.apache.org/jira/browse/COUCHDB-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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] 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] 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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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-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] 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 pHello there, {name}/p
so it would be possible to require something like this
templates/master.html --
html
head
titletitle/title
/head
body
pThat's my content/p
/body
/html
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] 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-tabpanelfocusedCommentId=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] 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-707) Proposal for Filter Views
[ https://issues.apache.org/jira/browse/COUCHDB-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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] Commented: (COUCHDB-709) Restart actually restarts the server
[
https://issues.apache.org/jira/browse/COUCHDB-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] Commented: (COUCHDB-686) Improve ordering of replication
[ https://issues.apache.org/jira/browse/COUCHDB-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-658) Add CommonJS style modules to the view server
[ https://issues.apache.org/jira/browse/COUCHDB-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835411#action_12835411 ] Chris Anderson commented on COUCHDB-658: Cool! Glad to see it working. Is there a way to make it work without keeping everything in the modules subtree? Eg I might want to require(vendor/crypto/sha) or maybe even require the validation function in a update handler to give users more nicely formatted error messages. I guess this is gonna pretty much require that people are requiring commonjs modules not arbitrary javascript, so feel free to tell me to shut up. :) But I still might want to publish some commonjs modules as part of a vendor with other JS (like browser code) so maybe it makes sense to have the require namespace be the full ddoc, and if someone says require(views/foo/map) they can suffer the error that comes from trying to import a raw function as a commonjs module. 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 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. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12835421#action_12835421
]
Chris Anderson commented on COUCHDB-658:
That won't do as couchapp will import a filesystem tree in modules as:
{
modules: {
vendor : {
crypto : {
sha : code
}
}
}
}
So while you could do the thing you described above it'd be unlikely to be used
unless couchapp adopts special behavior for the treatment of the modules
directory, which I'd like to avoid.
Adding the tree traversal stuff shouldn't be hard and we should get the ability
to stick modules anywhere (the ddoc/vendor/foo/commonjs/bar location will be
popular)
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
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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12835422#action_12835422
]
Chris Anderson commented on COUCHDB-658:
@benoit
I don't think we should remove the couchapp macros as they are compatible with
all kinds of messy old code, not just commonjs modules.
As far as the JSON macro goes, it is already not strictly necessary outside of
map and reduce, as the ddoc is present as 'this' so you can do:
function(req, doc) {
var template = this.my_templates.some_stuff.the_template;
...
}
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
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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12835431#action_12835431 ] Chris Anderson commented on COUCHDB-658: I'd say the additional code is well worth it. I hadn't thought about relative require, but I think that will also not be so hard. And I'd suggest again that the conceptual module name space root should be the ddoc, so we can require things outside of ddoc.modules. If we say that the root is ddoc.modules then we are suddenly giving a weird sense of security guarantees (some crazy person might get the idea that data in eg ddoc.secret can't be accessed from shows and lists, or something...) I think if we fail hard when someone tries to require(views/foo/reduce) that's just fine, although it'd be nice to give a helpful error message. 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 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. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12835550#action_12835550 ] Chris Anderson commented on COUCHDB-658: We still need the necessary error handling for cases where eg the ddoc.modules.foo == [array, of, stuff, 3] or is otherwise not valid, so the case where a user tries to require shows/blah doesn't trouble me. 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 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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-654) The edit DB security object dialog is broken
[ https://issues.apache.org/jira/browse/COUCHDB-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-654. -- Resolution: Fixed applied in e910054. backported to 0.11.x in r910055 thanks! The edit DB security object dialog is broken Key: COUCHDB-654 URL: https://issues.apache.org/jira/browse/COUCHDB-654 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 0.11 Environment: trunk / 0.11 Reporter: Filipe Manana Fix For: 0.11 Attachments: futon-edit-db-security-object-trunk.patch The edit DB security object dialog's code is not up to date, still behaving like _admins and _readers URIs exist. The following patch fixes 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-650) Add now option for ?since parameter on _changes
[ https://issues.apache.org/jira/browse/COUCHDB-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832859#action_12832859 ] Chris Anderson commented on COUCHDB-650: The problem with since=now is that it can lead to missed updates. There should be a ticket to make view responses include the view_seq and to expose doc._local_seq via a GET parameter. It's much better to know what seq your state is current as of, than to miss updates. 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 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] Assigned: (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:all-tabpanel ] Chris Anderson reassigned COUCHDB-649: -- Assignee: Chris Anderson 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-632) Generic _changes listener added to jquery.couch.js
[ https://issues.apache.org/jira/browse/COUCHDB-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12831780#action_12831780 ] Chris Anderson commented on COUCHDB-632: If there were a Futon page of the 50 most recent _changes entries as they were being created / edited (using the All Documents ui) people would really appreciate this patch. Because that would rule. Generic _changes listener added to jquery.couch.js -- Key: COUCHDB-632 URL: https://issues.apache.org/jira/browse/COUCHDB-632 Project: CouchDB Issue Type: Improvement Components: Futon Environment: the Browser! Reporter: mikeal Priority: Minor Attachments: changes.diff, changes1.diff, jquery.couch.js Original Estimate: 0.02h Remaining Estimate: 0.02h I've written a Generic _changes listener and added it to jquery.couch.js taken from Futon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-632) Generic _changes listener added to jquery.couch.js
[ https://issues.apache.org/jira/browse/COUCHDB-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12831781#action_12831781 ] Chris Anderson commented on COUCHDB-632: ooh and you could even allow people to specify filters. Generic _changes listener added to jquery.couch.js -- Key: COUCHDB-632 URL: https://issues.apache.org/jira/browse/COUCHDB-632 Project: CouchDB Issue Type: Improvement Components: Futon Environment: the Browser! Reporter: mikeal Priority: Minor Attachments: changes.diff, changes1.diff, jquery.couch.js Original Estimate: 0.02h Remaining Estimate: 0.02h I've written a Generic _changes listener and added it to jquery.couch.js taken from Futon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COUCHDB-617) Large integers being turned into floats
[
https://issues.apache.org/jira/browse/COUCHDB-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson reassigned COUCHDB-617:
--
Assignee: Chris Anderson
Large integers being turned into floats
---
Key: COUCHDB-617
URL: https://issues.apache.org/jira/browse/COUCHDB-617
Project: CouchDB
Issue Type: Bug
Environment: 0.11.0b894112
Ubuntu Karmic
standard erlang 13.b.1 package
xulrunner 1.9.1.6
Reporter: Brian Candler
Assignee: Chris Anderson
Attachments: couchdb-test-json.diff
Somewhere between the view server and the client, large integer values are
having .0 appended to make them look like floats.
This is OK:
$ curl -X POST -d '{map:function(doc) { emit(20,null); }}'
http://127.0.0.1:5984/test_suite_db/_temp_view
{total_rows:3,offset:0,rows:[
{id:bar,key:20,value:null},
{id:baz,key:20,value:null},
{id:foo,key:20,value:null}
]}
But here's a large integer getting the .0 appended:
$ curl -X POST -d '{map:function(doc) { emit(1262958680124,null); }}'
http://127.0.0.1:5984/test_suite_db/_temp_view
{total_rows:3,offset:0,rows:[
{id:bar,key:1262958680124.0,value:null},
{id:baz,key:1262958680124.0,value:null},
{id:foo,key:1262958680124.0,value:null}
]}
And some values are getting turned into exponential format:
$ curl -X POST -d '{map:function(doc) { emit(30,null); }}'
http://127.0.0.1:5984/test_suite_db/_temp_view
{total_rows:3,offset:0,rows:[
{id:bar,key:3.0e+9,value:null},
{id:baz,key:3.0e+9,value:null},
{id:foo,key:3.0e+9,value:null}
]}
It appears to affect integers larger than 2^31, but these are still much
smaller than the 2^48 mantissa of IEEE double precision (which Javascript
uses). Hence they should be accurately represented as integers, not floats.
If I run the view server by itself from the command line, all works properly:
$ bin/couchjs share/server/main.js
[reset]
true
[add_fun,function(doc) { emit(1262958680124,null); }]
true
[add_fun,function(doc) { emit(30,null); }]
true
[map_doc,{}]
[[[1262958680124,null]], [[30,null]]]
Therefore it looks like the problem is in the Erlang JSON deserialisation
side. i.e. it's not keeping these values as large integers, when it could be.
NOTE: I have another machine, running a similar recent couchdb trunk
(0.11.0b894828) plus Ubuntu Karmic Server Edition built against libmozjs
1.8.1.16 (not xulrunner). This exhibits the same behaviour as above.
But the problem *doesn't* appear on another, older CouchDB installation I
have. This is 0.11.0a813819 running under Ubuntu Hardy, with erlang 12.b.5
and libmozjs 1.8.1.18
{total_rows:1,offset:0,rows:[
{id:person,key:30,value:null}
]}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-643) why is this a conflict
[
https://issues.apache.org/jira/browse/COUCHDB-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-643.
--
Resolution: Duplicate
Questions like this are a better fit for the mailing list:
http://couchdb.apache.org/community/lists.html
I think the answer is that you need to provide the _rev as part of the JSON
body. This isn't because you are wrong, it's because CouchDB still has some
code that needs to be written. I think this is addressed in COUCHDB-642
Cheers,
Chris
why is this a conflict
--
Key: COUCHDB-643
URL: https://issues.apache.org/jira/browse/COUCHDB-643
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 0.10.1
Environment: linux-ubuntu x86_64
Reporter: Meno Abels
Hello
if you add this document to the db:
curl -X PUT http://127.0.0.1:5984/test-db/test-doc \
-H Content-type: application/json \
--data
{\_attachments\:{\raw\:{\data\:\anVzdCBhIHNob3J0IHN0cmluZw==\,
\content_type\:\plain/text\}}}
{ok:true,id:test-doc,rev:1-e3c177696acf6057b12ad6e1bc883625}
and than try to update it
curl -X PUT
http://127.0.0.1:5984/test-db/test-doc?rev=1-e3c177696acf6057b12ad6e1bc883625
\
-H Content-type: application/json \
--data {\foo\:\bar\}
{error:conflict,reason:Document update conflict.}
take care of the correct rev numbers.
What is my fault?
thx in advance
meno
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-637) more info in #http available to handler
[ https://issues.apache.org/jira/browse/COUCHDB-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12828672#action_12828672 ] Chris Anderson commented on COUCHDB-637: I've got nothing against this but I'd suggest the change should be part of a patch that makes use of it. more info in #http available to handler --- Key: COUCHDB-637 URL: https://issues.apache.org/jira/browse/COUCHDB-637 Project: CouchDB Issue Type: Improvement Affects Versions: 0.11, 0.12 Reporter: Benoit Chesneau Attachments: http_record.diff Attached is a diff that add default_fun and url_handlers to #http. It's useful for any custom handler that need to use the http_handler and not only the db and design http handlers. Like for example in the rewriter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-512) Per-DB Authorization and ACL
[ https://issues.apache.org/jira/browse/COUCHDB-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-512. -- Resolution: Fixed I just committed a similar feature (with a different implementation). Closing this as fixed. Per-DB Authorization and ACL Key: COUCHDB-512 URL: https://issues.apache.org/jira/browse/COUCHDB-512 Project: CouchDB Issue Type: New Feature Components: Database Core Reporter: Jason Davies Assignee: Jason Davies Fix For: 0.11 Attachments: per_db_auth.1.patch, per_db_auth.patch Following discussions on the mailing list, this is for tracking work and comments surrounding an implementation of per-db authorization and ACL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-273) view rows should be able to include _rev
[
https://issues.apache.org/jira/browse/COUCHDB-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-273.
--
Resolution: Fixed
this has been fixed for a while. Now you can use _id and _rev in view values to
direct include docs. This is think satisfies the request.
view rows should be able to include _rev
Key: COUCHDB-273
URL: https://issues.apache.org/jira/browse/COUCHDB-273
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Reporter: Louis Gerbarg
In our project we use maps in order to group objects, but do not generate any
interesting any meaningful data to return from the mapping function aside
from the sorted ordering. Our client basically does a GET against the view to
determine what objects are in for a key. It has a local cache, and currently
it then HEADs every object returned by that view to see if the objects need
to be reloaded. If the rev was included in the row that would be unnecessary.
Currently we are intending to return { rev : doc._rev } out of the mapping
function, but the seems a bit clumsy.
Jan suggested in irc that maybe the correct thing to do is to remove the
_id from the roes by default and add both _rev and _id with an option
(include_meta=true). This approach seems good to me, since I suspect people
who are using views to manipulate the data in interesting ways generally
don't need the object ids, and people who are using views primarily to
organize objects almost always need the rev in addition to the object id.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-635) A document with a field named 'constructor' causes it to silently be excluded from any and all map views
[
https://issues.apache.org/jira/browse/COUCHDB-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806803#action_12806803
]
Chris Anderson commented on COUCHDB-635:
when 0.11 is released (next week I hope) the new JSON handler should make it in
there which should have this issue.
For now I suggest deleting the offending doc or changing the names.
I'm unable to reproduce on trunk.
If you do try trunk, please be aware that you might not be able to downgrade
your file to 0.10 afterwards so you want to use a copy of your data.
A document with a field named 'constructor' causes it to silently be excluded
from any and all map views
Key: COUCHDB-635
URL: https://issues.apache.org/jira/browse/COUCHDB-635
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 0.10.1
Environment: Mac OS X 10.6.2, CouchDB 0.10.1
Reporter: James Cash
Priority: Minor
If a document has a (nested) field named 'constructor', any map which
attempts to emit the document will instead silently discard it.
For example, the document
{ _id: CSC190H1S,
_rev: 32-287eec55e59305ee94129a0be940bf41,
outcomes: {
constructor: [
knowledge
]
}
}
will silently be excluded by any view which attempts to emit doc or
doc.outcomes .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-631) Replication by doc Ids
[ https://issues.apache.org/jira/browse/COUCHDB-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-631. -- Resolution: Fixed latest patch applied in r904615 Thanks Filipe! Replication by doc Ids -- Key: COUCHDB-631 URL: https://issues.apache.org/jira/browse/COUCHDB-631 Project: CouchDB Issue Type: New Feature Components: Replication Environment: trunk Reporter: Filipe Manana Assignee: Chris Anderson Priority: Minor Attachments: couchdb-631-rep-doc-ids-trunk-git-2nd-try.patch, couchdb-631-rep-doc-ids-trunk-git.patch, replication-by-doc-ids-alternative-impl-2_trunk.patch, replication-by-doc-ids-alternative-impl_trunk.patch, replication-by-doc-ids_trunk.patch The following patch adds support for the optional doc_ids attribute (array of strings) of a JSON replication object. The idea was suggested recently by Chris Anderson in the dev mailing list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-583) storing attachments in compressed form and serving them in compressed form if accepted by the client
[ https://issues.apache.org/jira/browse/COUCHDB-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-583. -- Resolution: Fixed committed in r904650 Thanks for the hard work everyone! storing attachments in compressed form and serving them in compressed form if accepted by the client Key: COUCHDB-583 URL: https://issues.apache.org/jira/browse/COUCHDB-583 Project: CouchDB Issue Type: New Feature Components: Database Core, HTTP Interface Environment: CouchDB trunk Reporter: Filipe Manana Attachments: couchdb-583-trunk-10th-try.patch, couchdb-583-trunk-11th-try.patch, couchdb-583-trunk-12th-try.patch, couchdb-583-trunk-13th-try.patch, couchdb-583-trunk-14th-try-git.patch, couchdb-583-trunk-15th-try-git.patch, couchdb-583-trunk-16th-try-git.patch, couchdb-583-trunk-17th-try-git.patch, couchdb-583-trunk-18th-try-git.patch, couchdb-583-trunk-3rd-try.patch, couchdb-583-trunk-4th-try-trunk.patch, couchdb-583-trunk-5th-try.patch, couchdb-583-trunk-6th-try.patch, couchdb-583-trunk-7th-try.patch, couchdb-583-trunk-8th-try.patch, couchdb-583-trunk-9th-try.patch, jira-couchdb-583-1st-try-trunk.patch, jira-couchdb-583-2nd-try-trunk.patch This feature allows Couch to gzip compress attachments as they are being received and store them in compressed form. When a client asks for downloading an attachment (e.g. GET somedb/somedoc/attachment.txt), the attachment is sent in compressed form if the client's http request has gzip specified as a valid transfer encoding for the response (using the http header Accept-Encoding). Otherwise couch decompresses the attachment before sending it back to the client. Attachments are compressed only if their MIME type matches one of those listed in a separate config file. Compression level is also configurable in the default.ini file. This follows Damien's suggestion from 30 November: Perhaps we need a separate user editable ini file to specify compressable or non-compressable files (would probably be too big for the regular ini file). What do other web servers do? Also, a potential optimization is to compress the file while writing to disk, and serve the compressed bytes directly to clients that can handle it, and decompressed for those that can't. For compressable types, it's a win for both disk IO for reads and writes, and CPU on read. Patch 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-591) _rewrite handler
[ https://issues.apache.org/jira/browse/COUCHDB-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806552#action_12806552 ] Chris Anderson commented on COUCHDB-591: I think this is close, however, it'd be nice to see a broader test suite. Eg, can I rewrite the query string parameters? Can I rewrite to 2 different endpoints depending on the verb? These tests are the best documentation, so having a fuller set would help a lot. _rewrite handler Key: COUCHDB-591 URL: https://issues.apache.org/jira/browse/COUCHDB-591 Project: CouchDB Issue Type: New Feature Components: HTTP Interface Affects Versions: 0.11 Reporter: Benoit Chesneau Attachments: couch_httpd_rewriter2.diff, couchdb_rewrite.patch Find attached a patch providing simple url rewritig in CouchDB. You can also find it in my github repo : http://github.com/benoitc/couchdb/tree/rewrite The design is very simple. Everything is managed via a simple javascript function that return a path or throw 'forbidden', 'unauthorized' and not found errors. The request object is passed to the function and then depending on the path, verb or userCtx you could decide how to rewrite the path. All relatives path are relative to design doc. The _rewriter is available at db or _design level : /db/_rewrite/designname/path or /db/_design/designame/_rewrite/path. Then _rewrite handler look in design doc if `rewrite` member exists and load the function. A snippet is avalaible here : http://markmail.org/message/4alwtb2zzgwu7iz7 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
