Re: Ready for 0.10 Release?
On Tue, Aug 18, 2009 at 01:34, Jan Lehnardtj...@apache.org wrote: I'd like the history patch to be simmering in the 0.10.x branch. I'm working on another patch to provide view options in Futon. Would it be possible to include that for 0.10 as well? Also, I wonder if my HATEOAS patches ever went anywhere (I put them in the tracker, don't remember where right now). Basically, it would be nice if it was possible to find all the special URLs from the root without having to know any beforehand. Cheers, Dirkjan
Re: reduce_limit error
function most_recent_reading-map(doc) {
if(doc.type === TemperatureReading) {
emit(doc.station_id, doc);
}
}
function most_recent_reading-reduce(keys, values) {
var sorted = values.sort(function (a,b) {
return b.created_at.localeCompare(a.created_at)
});
return sorted[0];
}
you should never accumulate a list in a reduce function...
if you want to create a compressed final JSON output, the thing to do
would be to run a list function on a group reduce query, and have it
make the final aggregate. that way you don't end up with an infinitely
long overflowing list in your reduce values.
Given that the reduce function returns a single value, I don't
understand why you consider it to be accumulating a list. I see it as
being roughly equivalent to returning a very large scalar.
As the argument against having the output of a reduce function grow
too fast is based on degraded performance with a large dataset, I ran
a test case with 1 million docs. The query returns in about 0.03s,
which is significantly faster than a group_level based query against a
dataset of a similar size.
Paul
[jira] Commented: (COUCHDB-471) make distcheck fails
[ https://issues.apache.org/jira/browse/COUCHDB-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744412#action_12744412 ] Benoit Chesneau commented on COUCHDB-471: - make distcheck fails on OpenBSD : http://friendpaste.com/7KzkVvIq15fza5xP1iucHf make distcheck fails Key: COUCHDB-471 URL: https://issues.apache.org/jira/browse/COUCHDB-471 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 0.10 Environment: Mac OS X Reporter: Jan Lehnardt Assignee: Paul Joseph Davis Priority: Critical Fix For: 0.10 make[2]: *** No rule to make target `local.ini', needed by `distdir'. Stop. make[1]: *** [distdir] Error 1 make: *** [distdir] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r804427 - in /couchdb/trunk: etc/couchdb/default.ini.tpl.in share/www/script/test/delayed_commits.js src/couchdb/couch_db.erl src/couchdb/couch_httpd_db.erl
On Sat, Aug 15, 2009 at 10:17:28AM -0700, Chris Anderson wrote: One middle ground implementation that could work for throughput, would be to use the batch=ok ets based storage, but instead of immediately returning 202 Accepted, hold the connection open until the batch is written, and return 201 Created after the batch is written. This would allow the server to optimize batch size, without the client needing to worry about things, and we could return 201 Created and maintain our strong consistency guarantees. Do you mean default to batch=ok behaviour? (In which case, if you don't want to batch you'd specify something else, e.g. x-couch-full-commit: true?) This is fine by me. Of course, clients doing sequential writes may see very poor performance (i.e. write - wait response - write - wait response etc). However this approach should work well with HTTP pipelining, as well as with clients which open multiple concurrent HTTP connections. The replicator would need to do pipelining, if it doesn't already. As I was attempting to say before: any solution which makes write guarantees should expose behaviour which is meaningful to the client. - there's no point doing a full commit on every write unless you delay the HTTP response until after the commit (otherwise there's still a window where the client thinks the data has still gone safely to disk, but actually it could be lost) - there's no point having two different forms of non-safe write, because there's no reasonable way for the client to choose between them. Currently we have 'batch=ok', and we also have a normal write without 'x-couch-full-commit: true' - both end up with the data sitting in RAM for a while before going to disk, the difference being whether it's Erlang RAM or VFS buffer cache RAM. I like the idea of being able to tune the batch size internally within the server. This could allow CouchDB to automatically adjust for performance without changing consistency guarantees, eg: run large batches when under heavy load, but when accessed by a single user, just do full_commits all the time. I agree. I also think it would be good to be able to tune this per DB, or more simply, per write. e.g. a PUT request could specify max_wait=2000 (if not specified, use a default value from the ini file). Subsequent requests could specify their own max_wait params, and a full commit would occur when the earliest of these times occurs. max_wait=0 would then replace the x-couch-full-commit: header, which seems like a bit of a frig to me anyway. from being resource hogs by specifying a min_wait in the ini file. That is, if you set min_wait=100, then any client which insists on having a full commit by specifying max_wait=0 may find itself delayed up to 0.1s before its request is honoured. Regards, Brian.
Re: continuous replication API discussion
I wouldn't completely replace the current .ini configuration files with a database -- I think there's real value in being able to change some settings without the server running. Agreed, there are certain classes of configuration data you'd want in a database and others you'd want in an ini. Whether you want to easily replicate it is probably a good guide where it should go... Cheers Simon
Re: reduce_limit error
On Sun, Aug 16, 2009 at 05:55:56PM +0100, Robert Newson wrote: You can turn it off (caveat emptor); ; Changing reduce_limit to false will disable reduce_limit. ; If you think you're hitting reduce_limit with a good reduce function, ; please let us know on the mailing list so we can fine tune the heuristic. [query_server_config] reduce_limit = true I think that it should be a limit in bytes, not a true/false. I have also had cases where I generate a limited-sized reduce value which is a bit larger than 200 bytes.
[jira] Updated: (COUCHDB-465) Produce sequential, but unique, document id's
[ https://issues.apache.org/jira/browse/COUCHDB-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-465: -- Attachment: uuid_generator.patch Use couch_config:register and a refactoring of handle_call. Produce sequential, but unique, document id's - Key: COUCHDB-465 URL: https://issues.apache.org/jira/browse/COUCHDB-465 Project: CouchDB Issue Type: Improvement Reporter: Robert Newson Attachments: sequence_id.patch, uuid_generator.patch, uuid_generator.patch, uuid_generator.patch Currently, if the client does not specify an id (POST'ing a single document or using _bulk_docs) a random 16 byte value is created. This kind of key is particularly brutal on b+tree updates and the append-only nature of couchdb files. Attached is a patch to change this to a two-part identifier. The first part is a random 12 byte value and the remainder is a counter. The random prefix is rerandomized when the counter reaches its maximum. The rollover in the patch is at 16 million but can obviously be changed. The upshot is that the b+tree is updated in a better fashion, which should lead to performance benefits. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-465) Produce sequential, but unique, document id's
[ https://issues.apache.org/jira/browse/COUCHDB-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-465: -- Attachment: (was: uuid_generator.patch) Produce sequential, but unique, document id's - Key: COUCHDB-465 URL: https://issues.apache.org/jira/browse/COUCHDB-465 Project: CouchDB Issue Type: Improvement Reporter: Robert Newson Attachments: uuid_generator.patch, uuid_generator.patch Currently, if the client does not specify an id (POST'ing a single document or using _bulk_docs) a random 16 byte value is created. This kind of key is particularly brutal on b+tree updates and the append-only nature of couchdb files. Attached is a patch to change this to a two-part identifier. The first part is a random 12 byte value and the remainder is a counter. The random prefix is rerandomized when the counter reaches its maximum. The rollover in the patch is at 16 million but can obviously be changed. The upshot is that the b+tree is updated in a better fashion, which should lead to performance benefits. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-465) Produce sequential, but unique, document id's
[ https://issues.apache.org/jira/browse/COUCHDB-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-465: -- Attachment: (was: uuid_generator.patch) Produce sequential, but unique, document id's - Key: COUCHDB-465 URL: https://issues.apache.org/jira/browse/COUCHDB-465 Project: CouchDB Issue Type: Improvement Reporter: Robert Newson Attachments: uuid_generator.patch Currently, if the client does not specify an id (POST'ing a single document or using _bulk_docs) a random 16 byte value is created. This kind of key is particularly brutal on b+tree updates and the append-only nature of couchdb files. Attached is a patch to change this to a two-part identifier. The first part is a random 12 byte value and the remainder is a counter. The random prefix is rerandomized when the counter reaches its maximum. The rollover in the patch is at 16 million but can obviously be changed. The upshot is that the b+tree is updated in a better fashion, which should lead to performance benefits. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-471) make distcheck fails
[ https://issues.apache.org/jira/browse/COUCHDB-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Chesneau updated COUCHDB-471: Attachment: couchdb-licence_skip.patch attached diff suggested by jan fix previous error. But now I get following error : gmake[5]: Leaving directory `/home/benoitc/tmp/couchdb/apache-couchdb-0.10.0a805351/_build/etc' gmake[4]: Leaving directory `/home/benoitc/tmp/couchdb/apache-couchdb-0.10.0a805351/_build/etc' gmake[3]: Leaving directory `/home/benoitc/tmp/couchdb/apache-couchdb-0.10.0a805351/_build/etc' gmake[2]: Leaving directory `/home/benoitc/tmp/couchdb/apache-couchdb-0.10.0a805351/_build/etc' Making install in src/couchdb gmake[2]: Entering directory `/home/benoitc/tmp/couchdb/apache-couchdb-0.10.0a805351/_build/src/couchdb' Making install in priv gmake[3]: Entering directory `/home/benoitc/tmp/couchdb/apache-couchdb-0.10.0a805351/_build/src/couchdb/priv' gmake[4]: Entering directory `/home/benoitc/tmp/couchdb/apache-couchdb-0.10.0a805351/_build/src/couchdb/priv' gmake[4]: Nothing to be done for `install-exec-am'. test -z /priv || /bin/sh /home/benoitc/tmp/couchdb/apache-couchdb-0.10.0a805351/build-aux/install-sh -d /priv /bin/sh ../../../libtool --mode=install /usr/bin/install -c 'couchspawnkillable' '/priv/couchspawnkillable' /usr/bin/install -c couchspawnkillable /priv/couchspawnkillable install: /priv/couchspawnkillable: Permission denied gmake[4]: *** [install-couchprivPROGRAMS] Error 1 gmake[4]: Leaving directory `/home/benoitc/tmp/couchdb/apache-couchdb-0.10.0a805351/_build/src/couchdb/priv' gmake[3]: *** [install-am] Error 2 gmake[3]: Leaving directory `/home/benoitc/tmp/couchdb/apache-couchdb-0.10.0a805351/_build/src/couchdb/priv' gmake[2]: *** [install-recursive] Error 1 gmake[2]: Leaving directory `/home/benoitc/tmp/couchdb/apache-couchdb-0.10.0a805351/_build/src/couchdb' gmake[1]: *** [install-recursive] Error 1 gmake[1]: Leaving directory `/home/benoitc/tmp/couchdb/apache-couchdb-0.10.0a805351/_build' gmake: *** [distcheck] Error 2 make distcheck fails Key: COUCHDB-471 URL: https://issues.apache.org/jira/browse/COUCHDB-471 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 0.10 Environment: Mac OS X Reporter: Jan Lehnardt Assignee: Paul Joseph Davis Priority: Critical Fix For: 0.10 Attachments: couchdb-licence_skip.patch make[2]: *** No rule to make target `local.ini', needed by `distdir'. Stop. make[1]: *** [distdir] Error 1 make: *** [distdir] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-465) Produce sequential, but unique, document id's
[ https://issues.apache.org/jira/browse/COUCHDB-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-465: -- Attachment: uuid_generator.patch Updated to switch the _uuids misc handler to the server-selected uuid generation algorithm. Produce sequential, but unique, document id's - Key: COUCHDB-465 URL: https://issues.apache.org/jira/browse/COUCHDB-465 Project: CouchDB Issue Type: Improvement Reporter: Robert Newson Attachments: uuid_generator.patch, uuid_generator.patch Currently, if the client does not specify an id (POST'ing a single document or using _bulk_docs) a random 16 byte value is created. This kind of key is particularly brutal on b+tree updates and the append-only nature of couchdb files. Attached is a patch to change this to a two-part identifier. The first part is a random 12 byte value and the remainder is a counter. The random prefix is rerandomized when the counter reaches its maximum. The rollover in the patch is at 16 million but can obviously be changed. The upshot is that the b+tree is updated in a better fashion, which should lead to performance benefits. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Test suite problem with Hardy + 12.b.5
Now that couchdb trunk requires 12.b.5 I updated a Ubuntu Hardy box using
the Erlang from Jaunty, pulled in the latest Couchdb from git (*), and
compiled it.
It seems to start, but a lot of the tests fail, including the basics test.
The backtrace is attached below.
Any thoughts?
The backtrace is hard to read, but appears to be something to do with
_temp_view. The SpiderMonkey version I have installed is
libmozjs-dev 1.8.1.18+nobinonly.b308.cvs20090331t155113-0ubuntu0.8.04.1
and a quick test suggests it's OK:
$ /usr/local/bin/couchjs -
print(Hello);
^D
Hello
$
Cheers,
Brian.
(*) HEAD is:
commit f6c359e412ae3793de363ce23fdf34a09fd7107d
Author: jan j...@13f79535-47bb-0310-9956-ffa450edef68
Date: Tue Aug 18 10:03:43 2009 +
add Dirkjan Ochtman to THANKS file
git-svn-id: http://svn.apache.org/repos/asf/couchdb/tr...@805340
13f79535-47bb-0310-9956-ffa450edef68
- This is the log from running the basics test -
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'GET' / 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'DELETE'
/test_suite_db/ 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'DELETE'
/test_suite_db/ 404
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'PUT'
/test_suite_db/ 201
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'PUT'
/test_suite_db/ 412
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'DELETE'
/test_suite_db 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'PUT'
/test_suite_db 201
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'DELETE'
/test_suite_db%2Fwith_slashes 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'PUT'
/test_suite_db%2Fwith_slashes 201
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'GET'
/test_suite_db/ 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'GET'
/test_suite_db/ 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'PUT'
/test_suite_db/0 201
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'GET'
/test_suite_db/0?revs_info=true 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'GET'
/test_suite_db/0?local_seq=true 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'PUT'
/test_suite_db/1 201
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'PUT'
/test_suite_db/2 201
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'PUT'
/test_suite_db/3 201
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - - 'GET'
/test_suite_db/ 200
[Tue, 18 Aug 2009 12:25:45 GMT] [error] [0.716.0] {error_report,0.22.0,
{0.716.0,crash_report,
[[{pid,0.716.0},
{registered_name,[]},
{error_info,
{exit,
{bad_return_value,{os_process_error,{exit_status,2}}},
[{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}},
{initial_call,{couch_os_process,init,['Argument__1']}},
{ancestors,
[couch_query_servers,couch_secondary_services,couch_server_sup,
0.1.0]},
{messages,[]},
{links,[0.555.0]},
{dictionary,[]},
{trap_exit,false},
{status,running},
{heap_size,610},
{stack_size,23},
{reductions,217}],
[]]}}
[Tue, 18 Aug 2009 12:25:45 GMT] [error] [emulator] Error in process 0.714.0
with exit value:
{{nocatch,{'EXIT',{{badmatch,{error,{bad_return_value,{os_process_error,{exit_status,2},[{couch_query_servers,new_process,2},{couch_query_servers,handle_call,3},{gen_server,handle_msg,5},{proc_lib,init_p_do_apply...
[Tue, 18 Aug 2009 12:25:45 GMT] [error] [0.555.0] ** Generic server
couch_query_servers terminating
** Last message in was {'EXIT',0.716.0,
{bad_return_value,
{os_process_error,{exit_status,2
** When Server state == {213021,217120,221217,225305}
** Reason for termination ==
** {bad_return_value,{os_process_error,{exit_status,2}}}
[Tue, 18 Aug 2009 12:25:45 GMT] [error] [0.555.0] {error_report,0.22.0,
{0.555.0,crash_report,
[[{pid,0.555.0},
{registered_name,couch_query_servers},
{error_info,
{exit,
{bad_return_value,{os_process_error,{exit_status,2}}},
[{gen_server,terminate,6},{proc_lib,init_p_do_apply,3}]}},
{initial_call,{couch_query_servers,init,['Argument__1']}},
{ancestors,[couch_secondary_services,couch_server_sup,0.1.0]},
{messages,[]},
{links,[0.415.0]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,377},
{stack_size,23},
{reductions,271}],
[]]}}
[Tue, 18 Aug 2009 12:25:45 GMT] [error] [0.415.0] {error_report,0.22.0,
{0.415.0,supervisor_report,
[{supervisor,{local,couch_secondary_services}},
Re: Test suite problem with Hardy + 12.b.5
Hi Brian,
thanks for the report. Just for our sanity, can use the SVN checkout?
We can't support third party distributions (yeah, I know, sounds
silly :)
The backtrace looks as if the build or link phase of couchjs fails.
can you try running couchjs by hand and write `[reset]`? into
stdin?
src/couchdb/couchjs share/server/main.js
[reset]
true
And can you try following http://wiki.apache.org/couchdb/Troubleshooting?
Cheers
Jan
--
On 18 Aug 2009, at 14:37, Brian Candler wrote:
Now that couchdb trunk requires 12.b.5 I updated a Ubuntu Hardy box
using
the Erlang from Jaunty, pulled in the latest Couchdb from git (*), and
compiled it.
It seems to start, but a lot of the tests fail, including the
basics test.
The backtrace is attached below.
Any thoughts?
The backtrace is hard to read, but appears to be something to do with
_temp_view. The SpiderMonkey version I have installed is
libmozjs-dev
1.8.1.18+nobinonly.b308.cvs20090331t155113-0ubuntu0.8.04.1
and a quick test suggests it's OK:
$ /usr/local/bin/couchjs -
print(Hello);
^D
Hello
$
Cheers,
Brian.
(*) HEAD is:
commit f6c359e412ae3793de363ce23fdf34a09fd7107d
Author: jan j...@13f79535-47bb-0310-9956-ffa450edef68
Date: Tue Aug 18 10:03:43 2009 +
add Dirkjan Ochtman to THANKS file
git-svn-id: http://svn.apache.org/repos/asf/couchdb/tr...@805340
13f79535-47bb-0310-9956-ffa450edef68
- This is the log from running the basics test -
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'GET' / 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'DELETE' /test_suite_db/ 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'DELETE' /test_suite_db/ 404
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'PUT' /test_suite_db/ 201
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'PUT' /test_suite_db/ 412
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'DELETE' /test_suite_db 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'PUT' /test_suite_db 201
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'DELETE' /test_suite_db%2Fwith_slashes 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'PUT' /test_suite_db%2Fwith_slashes 201
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'GET' /test_suite_db/ 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'GET' /test_suite_db/ 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'PUT' /test_suite_db/0 201
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'GET' /test_suite_db/0?revs_info=true 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'GET' /test_suite_db/0?local_seq=true 200
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'PUT' /test_suite_db/1 201
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'PUT' /test_suite_db/2 201
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'PUT' /test_suite_db/3 201
[Tue, 18 Aug 2009 12:25:45 GMT] [info] [0.485.0] 127.0.0.1 - -
'GET' /test_suite_db/ 200
[Tue, 18 Aug 2009 12:25:45 GMT] [error] [0.716.0]
{error_report,0.22.0,
{0.716.0,crash_report,
[[{pid,0.716.0},
{registered_name,[]},
{error_info,
{exit,
{bad_return_value,{os_process_error,{exit_status,2}}},
[{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}},
{initial_call,{couch_os_process,init,['Argument__1']}},
{ancestors,
[couch_query_servers,couch_secondary_services,couch_server_sup,
0.1.0]},
{messages,[]},
{links,[0.555.0]},
{dictionary,[]},
{trap_exit,false},
{status,running},
{heap_size,610},
{stack_size,23},
{reductions,217}],
[]]}}
[Tue, 18 Aug 2009 12:25:45 GMT] [error] [emulator] Error in process
0.714.0 with exit value: {{nocatch,{'EXIT',{{badmatch,{error,
{bad_return_value,{os_process_error,{exit_status,2},
[{couch_query_servers,new_process,2},
{couch_query_servers,handle_call,3},{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply...
[Tue, 18 Aug 2009 12:25:45 GMT] [error] [0.555.0] ** Generic
server couch_query_servers terminating
** Last message in was {'EXIT',0.716.0,
{bad_return_value,
{os_process_error,{exit_status,2
** When Server state == {213021,217120,221217,225305}
** Reason for termination ==
** {bad_return_value,{os_process_error,{exit_status,2}}}
[Tue, 18 Aug 2009 12:25:45 GMT] [error] [0.555.0]
{error_report,0.22.0,
{0.555.0,crash_report,
[[{pid,0.555.0},
{registered_name,couch_query_servers},
{error_info,
{exit,
{bad_return_value,{os_process_error,{exit_status,2}}},
[{gen_server,terminate,6},{proc_lib,init_p_do_apply,
3}]}},
Re: Test suite problem with Hardy + 12.b.5
Supplementary info: I found the whole test suite was OK if I recompiled at commit a38260e61a94ce51aa91088b65043c60c97e3cb1. So I did a git-bisect between the two. All very clever, but then I recompiled back at HEAD, and it now works fine there too :-( I have been doing exactly the same every time I compile: ./bootstrap ./configure make sudo make install sudo /usr/local/etc/init.d/couchdb restart followed by a shift-reload in the browser on couch_tests.js Back at HEAD, I've done a 'make clean' followed by the above line again and it still works. So I guess this is a non-problem. It would be nice to know why it didn't work in the first place though. Regards, Brian. P.S. Minor problem when working with git: there is a src/couchdb/priv/couchspawnkillable file lying around which causes problems when switching between revisions using git checkout or git bisect. e.g. $ git-bisect bad Bisecting: 0 revisions left to test after this error: Untracked working tree file 'src/couchdb/priv/couchspawnkillable' would be overwritten by merge. $ rm src/couchdb/priv/couchspawnkillable $ git bisect bad Bisecting: 0 revisions left to test after this [ce8fb60c59e97ff0c960eb8b4819b53dd0eb18fd] allow list function and view function to be in different design docs, patch by Mark Hammond, closes COUCHDB-446 $ Not sure what the solution is. P.P.S. FWIW, here's the bisect log, although it's a red herring since HEAD now runs fine on my machine. $ git bisect log git-bisect start # bad: [f6c359e412ae3793de363ce23fdf34a09fd7107d] add Dirkjan Ochtman to THANKS file git-bisect bad f6c359e412ae3793de363ce23fdf34a09fd7107d # good: [a38260e61a94ce51aa91088b65043c60c97e3cb1] Introduces native Erlang query servers. Closes COUCHDB-377 git-bisect good a38260e61a94ce51aa91088b65043c60c97e3cb1 # good: [1dec07a650ee33364d74e61ebebfa09433fdfeb3] Make POST's reflect a provided _id member. git-bisect good 1dec07a650ee33364d74e61ebebfa09433fdfeb3 # good: [013a44367ad8142c0fa5ccb5f0d862bc7ffd0b7e] Updated license.skip. Added license to test/run_native_process.es git-bisect good 013a44367ad8142c0fa5ccb5f0d862bc7ffd0b7e # bad: [b67be9966bf4acb34e5833c0cadb3b00896ae374] Minor issue with make install not installing couchspawnkillable. git-bisect bad b67be9966bf4acb34e5833c0cadb3b00896ae374 # bad: [9e673e51ee0ce10963da49ce60eeaad0b7fee60c] Applying markh's Windows build patch. git-bisect bad 9e673e51ee0ce10963da49ce60eeaad0b7fee60c # bad: [9e673e51ee0ce10963da49ce60eeaad0b7fee60c] Applying markh's Windows build patch. git-bisect bad 9e673e51ee0ce10963da49ce60eeaad0b7fee60c # good: [ce8fb60c59e97ff0c960eb8b4819b53dd0eb18fd] allow list function and view function to be in different design docs, patch by Mark Hammond, closes COUCHDB-446 git-bisect good ce8fb60c59e97ff0c960eb8b4819b53dd0eb18fd -- 9e673e51ee0ce10963da49ce60eeaad0b7fee60c is first bad commit commit 9e673e51ee0ce10963da49ce60eeaad0b7fee60c Author: davisp dav...@13f79535-47bb-0310-9956-ffa450edef68 Date: Tue Aug 18 01:27:03 2009 + Applying markh's Windows build patch. Fixes COUCHDB-406 git-svn-id: http://svn.apache.org/repos/asf/couchdb/tr...@805243 13f79535-47bb-0310-9956-ffa450edef68 --
[jira] Created: (COUCHDB-472) handle custom CouchdDB welcome page
handle custom CouchdDB welcome page
---
Key: COUCHDB-472
URL: https://issues.apache.org/jira/browse/COUCHDB-472
Project: CouchDB
Issue Type: Improvement
Affects Versions: 0.10
Reporter: Benoit Chesneau
Fix For: 0.10
Attachments: couchdb_welcome.patch
This change modify behaviour of Welcome handler by allowing admin to customize
the welcome page. If content is application/json it will send current json
object, if not, it will send an html page or redirect to another path.
This patch change the confugration string to a tupple {WelcomeMsg,
WelcomePage}. WelcomePage could be a string for DocumentRoot where it will find
welcome.html page or a tupple {redirect, Url}
Ex if in config you have:
/ = {couch_httpd_misc_handlers, handle_welcome_req, {Welcome,
/usr/local/share/couchdb/www}}
If Accept content is application/json Couchdb will send :
couchdb:Welcome,version:0.10.0a}
If other it will send welcome.html.
if you replace /usr/local/share/couchdb/www by {redirect, /_utils} user
will be redirected on futon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-472) handle custom CouchdDB welcome page
[
https://issues.apache.org/jira/browse/COUCHDB-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Chesneau updated COUCHDB-472:
Attachment: screenshot.png
screenshot of default html welcome page
handle custom CouchdDB welcome page
---
Key: COUCHDB-472
URL: https://issues.apache.org/jira/browse/COUCHDB-472
Project: CouchDB
Issue Type: Improvement
Affects Versions: 0.10
Reporter: Benoit Chesneau
Fix For: 0.10
Attachments: couchdb_welcome.patch, screenshot.png
This change modify behaviour of Welcome handler by allowing admin to
customize the welcome page. If content is application/json it will send
current json object, if not, it will send an html page or redirect to another
path.
This patch change the confugration string to a tupple {WelcomeMsg,
WelcomePage}. WelcomePage could be a string for DocumentRoot where it will
find welcome.html page or a tupple {redirect, Url}
Ex if in config you have:
/ = {couch_httpd_misc_handlers, handle_welcome_req, {Welcome,
/usr/local/share/couchdb/www}}
If Accept content is application/json Couchdb will send :
couchdb:Welcome,version:0.10.0a}
If other it will send welcome.html.
if you replace /usr/local/share/couchdb/www by {redirect,
/_utils} user will be redirected on futon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Test suite problem with Hardy + 12.b.5
On 18 Aug 2009, at 15:23, Brian Candler wrote: On Tue, Aug 18, 2009 at 02:48:00PM +0200, Jan Lehnardt wrote: We can't support third party distributions (yeah, I know, sounds silly :) Even if they are SHA1-identical to what's in SVN? Grr. It's all about removing variables to check for and the limited time we all have. Sorry :/ can you try running couchjs by hand and write `[reset]`? into stdin? If it happens again, I'll try this, thanks. But I just upgraded another Hardy box in the same way, and this one worked first time without problems. That's great to hear! Cheers Jan --
.NET API for CouchDB in the works
I am working on an open source .NET API for CouchDB called Ottoman. The project has gotten far enough now, that I thought I should mention it to you guys. The project's source is located here: http://github.com/sinesignal/ottoman/tree/master I wasn't sure if I should post this on the user's list or the dev list. I am sorry if I posted it on the wrong list. Thanks, Dale
[jira] Created: (COUCHDB-473) erlang_views.js (and other tests) not installed
erlang_views.js (and other tests) not installed --- Key: COUCHDB-473 URL: https://issues.apache.org/jira/browse/COUCHDB-473 Project: CouchDB Issue Type: Bug Components: Test Suite Environment: git f6c359e412ae3793de363ce23fdf34a09fd7107d git-svn-id: http://svn.apache.org/repos/asf/couchdb/tr...@805340 13f79535-47bb-0310-9956-ffa450edef68 Reporter: Brian Candler Priority: Minor erlang_views.js test is not installed, and it looks like two others are missing too. $ sudo make install | grep erlang_view $ ls /usr/local/share/couchdb/www/script/test | wc -l 53 $ ls share/www/script/test | wc -l 56 $ ls share/www/script/test /tmp/a $ ls /usr/local/share/couchdb/www/script/test /tmp/b $ diff -u /tmp/a /tmp/b --- /tmp/a 2009-08-18 14:30:00.0 +0100 +++ /tmp/b 2009-08-18 14:30:10.0 +0100 @@ -17,10 +17,8 @@ design_docs.js design_options.js design_paths.js -erlang_views.js etags_head.js etags_views.js -form_submit.js invalid_docids.js jsonp.js large_docs.js @@ -32,7 +30,6 @@ oauth.js purge.js recreate_doc.js -reduce_builtin.js reduce_false.js reduce.js replication.js I think this problem has occurred before. Ideally it would be good if loadScript() were able to raise an error, but I don't know if that's possible. Furthermore: even after fixing this, form_submit doesn't appear in the test suite, but there is a form_upload test. This appears to be just a naming inconsistency. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-473) erlang_views.js (and other tests) not installed
[ https://issues.apache.org/jira/browse/COUCHDB-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Candler updated COUCHDB-473: -- Attachment: add_missing_tests.diff erlang_views.js (and other tests) not installed --- Key: COUCHDB-473 URL: https://issues.apache.org/jira/browse/COUCHDB-473 Project: CouchDB Issue Type: Bug Components: Test Suite Environment: git f6c359e412ae3793de363ce23fdf34a09fd7107d git-svn-id: http://svn.apache.org/repos/asf/couchdb/tr...@805340 13f79535-47bb-0310-9956-ffa450edef68 Reporter: Brian Candler Priority: Minor Attachments: add_missing_tests.diff erlang_views.js test is not installed, and it looks like two others are missing too. $ sudo make install | grep erlang_view $ ls /usr/local/share/couchdb/www/script/test | wc -l 53 $ ls share/www/script/test | wc -l 56 $ ls share/www/script/test /tmp/a $ ls /usr/local/share/couchdb/www/script/test /tmp/b $ diff -u /tmp/a /tmp/b --- /tmp/a2009-08-18 14:30:00.0 +0100 +++ /tmp/b2009-08-18 14:30:10.0 +0100 @@ -17,10 +17,8 @@ design_docs.js design_options.js design_paths.js -erlang_views.js etags_head.js etags_views.js -form_submit.js invalid_docids.js jsonp.js large_docs.js @@ -32,7 +30,6 @@ oauth.js purge.js recreate_doc.js -reduce_builtin.js reduce_false.js reduce.js replication.js I think this problem has occurred before. Ideally it would be good if loadScript() were able to raise an error, but I don't know if that's possible. Furthermore: even after fixing this, form_submit doesn't appear in the test suite, but there is a form_upload test. This appears to be just a naming inconsistency. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-472) handle custom CouchdDB welcome page
[
https://issues.apache.org/jira/browse/COUCHDB-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Chesneau updated COUCHDB-472:
Attachment: couchdb_welcome2.patch
New version of the patch. It put back the old behaviour (json on frontpage) as
default while keeping new feature.
So config could be :
/ = {couch_httpd_misc_handlers, handle_welcome_req, Welcome}, the default
or
/ = {couch_httpd_misc_handlers, handle_welcome_req, {Welcome,
/Users/benoitc/work/couchdb/share/www}} , display an html page when Accept
header isn't application/json
or
/ = {couch_httpd_misc_handlers, handle_welcome_req, {Welcome, {redirect
/somepath}}} , to redirect to /somepath when Accept header isn't
application/json
handle custom CouchdDB welcome page
---
Key: COUCHDB-472
URL: https://issues.apache.org/jira/browse/COUCHDB-472
Project: CouchDB
Issue Type: Improvement
Affects Versions: 0.10
Reporter: Benoit Chesneau
Fix For: 0.10
Attachments: couchdb_welcome.patch, couchdb_welcome2.patch,
screenshot.png
This change modify behaviour of Welcome handler by allowing admin to
customize the welcome page. If content is application/json it will send
current json object, if not, it will send an html page or redirect to another
path.
This patch change the confugration string to a tupple {WelcomeMsg,
WelcomePage}. WelcomePage could be a string for DocumentRoot where it will
find welcome.html page or a tupple {redirect, Url}
Ex if in config you have:
/ = {couch_httpd_misc_handlers, handle_welcome_req, {Welcome,
/usr/local/share/couchdb/www}}
If Accept content is application/json Couchdb will send :
couchdb:Welcome,version:0.10.0a}
If other it will send welcome.html.
if you replace /usr/local/share/couchdb/www by {redirect,
/_utils} user will be redirected on 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-471) make distcheck fails
[ https://issues.apache.org/jira/browse/COUCHDB-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744503#action_12744503 ] Jan Lehnardt commented on COUCHDB-471: -- Fixed again in r805410. make distcheck fails Key: COUCHDB-471 URL: https://issues.apache.org/jira/browse/COUCHDB-471 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 0.10 Environment: Mac OS X Reporter: Jan Lehnardt Assignee: Paul Joseph Davis Priority: Critical Fix For: 0.10 Attachments: couchdb-licence_skip.patch make[2]: *** No rule to make target `local.ini', needed by `distdir'. Stop. make[1]: *** [distdir] Error 1 make: *** [distdir] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-472) handle custom CouchdDB welcome page
[
https://issues.apache.org/jira/browse/COUCHDB-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Chesneau updated COUCHDB-472:
Attachment: couchdb_welcome3.patch
mmm better patch. I mixed two changes in last one. sorry.
handle custom CouchdDB welcome page
---
Key: COUCHDB-472
URL: https://issues.apache.org/jira/browse/COUCHDB-472
Project: CouchDB
Issue Type: Improvement
Affects Versions: 0.10
Reporter: Benoit Chesneau
Fix For: 0.10
Attachments: couchdb_welcome.patch, couchdb_welcome2.patch,
couchdb_welcome3.patch, screenshot.png
This change modify behaviour of Welcome handler by allowing admin to
customize the welcome page. If content is application/json it will send
current json object, if not, it will send an html page or redirect to another
path.
This patch change the confugration string to a tupple {WelcomeMsg,
WelcomePage}. WelcomePage could be a string for DocumentRoot where it will
find welcome.html page or a tupple {redirect, Url}
Ex if in config you have:
/ = {couch_httpd_misc_handlers, handle_welcome_req, {Welcome,
/usr/local/share/couchdb/www}}
If Accept content is application/json Couchdb will send :
couchdb:Welcome,version:0.10.0a}
If other it will send welcome.html.
if you replace /usr/local/share/couchdb/www by {redirect,
/_utils} user will be redirected on futon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-473) erlang_views.js (and other tests) not installed
[ https://issues.apache.org/jira/browse/COUCHDB-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt closed COUCHDB-473. Resolution: Fixed Fix Version/s: 0.10 closed in r805416 and r805417. erlang_views.js (and other tests) not installed --- Key: COUCHDB-473 URL: https://issues.apache.org/jira/browse/COUCHDB-473 Project: CouchDB Issue Type: Bug Components: Test Suite Environment: git f6c359e412ae3793de363ce23fdf34a09fd7107d git-svn-id: http://svn.apache.org/repos/asf/couchdb/tr...@805340 13f79535-47bb-0310-9956-ffa450edef68 Reporter: Brian Candler Priority: Minor Fix For: 0.10 Attachments: add_missing_tests.diff erlang_views.js test is not installed, and it looks like two others are missing too. $ sudo make install | grep erlang_view $ ls /usr/local/share/couchdb/www/script/test | wc -l 53 $ ls share/www/script/test | wc -l 56 $ ls share/www/script/test /tmp/a $ ls /usr/local/share/couchdb/www/script/test /tmp/b $ diff -u /tmp/a /tmp/b --- /tmp/a2009-08-18 14:30:00.0 +0100 +++ /tmp/b2009-08-18 14:30:10.0 +0100 @@ -17,10 +17,8 @@ design_docs.js design_options.js design_paths.js -erlang_views.js etags_head.js etags_views.js -form_submit.js invalid_docids.js jsonp.js large_docs.js @@ -32,7 +30,6 @@ oauth.js purge.js recreate_doc.js -reduce_builtin.js reduce_false.js reduce.js replication.js I think this problem has occurred before. Ideally it would be good if loadScript() were able to raise an error, but I don't know if that's possible. Furthermore: even after fixing this, form_submit doesn't appear in the test suite, but there is a form_upload test. This appears to be just a naming inconsistency. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-471) make distcheck fails
[ https://issues.apache.org/jira/browse/COUCHDB-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744509#action_12744509 ] Noah Slater commented on COUCHDB-471: - Paul, please re-add $(top_srcdir) to the Makefile.am as this is required when people are building outside of the source tree. I was told to add this directly by some gurus on the Automake lists. make distcheck fails Key: COUCHDB-471 URL: https://issues.apache.org/jira/browse/COUCHDB-471 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 0.10 Environment: Mac OS X Reporter: Jan Lehnardt Assignee: Paul Joseph Davis Priority: Critical Fix For: 0.10 Attachments: couchdb-licence_skip.patch make[2]: *** No rule to make target `local.ini', needed by `distdir'. Stop. make[1]: *** [distdir] Error 1 make: *** [distdir] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
new format for continuous _changes feed
Hi folks, I was talking with aquarius and rnewson on IRC about a possible change to the format of the _changes feed. We agreed that it made more sense for the feed=continuous mode to emit individual newline-delimited valid JSON Objects and skip the commas that are currently included. This will allow consumers to split on newlines and immediately decode the result without any post-processing. feed=normal and feed=longpoll would stay unchanged. If there are no objections I can make this change today and update the replicator as well. Best, Adam
[jira] Commented: (COUCHDB-237) Futon page for creating test cases.
[ https://issues.apache.org/jira/browse/COUCHDB-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744515#action_12744515 ] Simon Thulbourn commented on COUCHDB-237: - I'll look into this later today, it would be rather nice to be able to do this. :) Futon page for creating test cases. --- Key: COUCHDB-237 URL: https://issues.apache.org/jira/browse/COUCHDB-237 Project: CouchDB Issue Type: New Feature Components: Administration Console, Test Suite Reporter: Paul Joseph Davis It'd help to have a Futon page that allowed us to write test cases directly in JavaScript. I'm not thinking of anything really fancy beyond a text box on a page that has couch.js and couch_test_runner.js loaded. Integration with a paste service for pasting links into IRC or email would also be awesome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: new format for continuous _changes feed
Adam Kocoloski wrote:
Hi folks, I was talking with aquarius and rnewson on IRC about a
possible change to the format of the _changes feed. We agreed that it
made more sense for the feed=continuous mode to emit individual
newline-delimited valid JSON Objects and skip the commas that are
currently included. This will allow consumers to split on newlines and
immediately decode the result without any post-processing. feed=normal
and feed=longpoll would stay unchanged.
So, just to confirm that I understand this correctly, the
feed=continuous mode would print lots of lines which look like this, one
for each change:
{seq:3,id:5643c5b300e3065839a5bde0b7332948,changes:[{rev:3-825cb35de44c433bfb2df415563a19de}]}
and if you pass since=whatever and there's more than one change since
then, the feed would start off containing more than one line?
sil
Re: new format for continuous _changes feed
On Aug 18, 2009, at 10:21 AM, Stuart Langridge wrote:
Adam Kocoloski wrote:
Hi folks, I was talking with aquarius and rnewson on IRC about a
possible change to the format of the _changes feed. We agreed that
it
made more sense for the feed=continuous mode to emit individual
newline-delimited valid JSON Objects and skip the commas that are
currently included. This will allow consumers to split on newlines
and
immediately decode the result without any post-processing.
feed=normal
and feed=longpoll would stay unchanged.
So, just to confirm that I understand this correctly, the
feed=continuous mode would print lots of lines which look like this,
one
for each change:
{seq:3,id:5643c5b300e3065839a5bde0b7332948,changes:
[{rev:3-825cb35de44c433bfb2df415563a19de}]}
and if you pass since=whatever and there's more than one change
since
then, the feed would start off containing more than one line?
sil
Exactly. In the case of a timeout I'm planning on the server sending
one last line
{last_seq: 1234}
Best, Adam
Re: new format for continuous _changes feed
2009/8/18 Adam Kocoloski kocol...@apache.org: Hi folks, I was talking with aquarius and rnewson on IRC about a possible change to the format of the _changes feed. We agreed that it made more sense for the feed=continuous mode to emit individual newline-delimited valid JSON Objects and skip the commas that are currently included. This will allow consumers to split on newlines and immediately decode the result without any post-processing. feed=normal and feed=longpoll would stay unchanged. If there are no objections I can make this change today and update the replicator as well. Best, Adam This change would be nice indeed. - benoît
Re: new format for continuous _changes feed
On 18 Aug 2009, at 15:32, Benoit Chesneau wrote: 2009/8/18 Adam Kocoloski kocol...@apache.org: Hi folks, I was talking with aquarius and rnewson on IRC about a possible change to the format of the _changes feed. We agreed that it made more sense for the feed=continuous mode to emit individual newline- delimited valid JSON Objects and skip the commas that are currently included. This will allow consumers to split on newlines and immediately decode the result without any post-processing. feed=normal and feed=longpoll would stay unchanged. If there are no objections I can make this change today and update the replicator as well. Best, Adam This change would be nice indeed. +1 -- Jason Davies www.jasondavies.com
Re: new format for continuous _changes feed
On Aug 18, 2009, at 10:42 AM, Jason Davies wrote: On 18 Aug 2009, at 15:32, Benoit Chesneau wrote: 2009/8/18 Adam Kocoloski kocol...@apache.org: Hi folks, I was talking with aquarius and rnewson on IRC about a possible change to the format of the _changes feed. We agreed that it made more sense for the feed=continuous mode to emit individual newline- delimited valid JSON Objects and skip the commas that are currently included. This will allow consumers to split on newlines and immediately decode the result without any post-processing. feed=normal and feed=longpoll would stay unchanged. If there are no objections I can make this change today and update the replicator as well. Best, Adam This change would be nice indeed. +1 Committed in r805430. Cheers, Adam
[jira] Commented: (COUCHDB-466) couchdb oauth doesn't work behind reverse proxy
[ https://issues.apache.org/jira/browse/COUCHDB-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744547#action_12744547 ] Jan Lehnardt commented on COUCHDB-466: -- Benoit, can you add a javascript test? couchdb oauth doesn't work behind reverse proxy --- Key: COUCHDB-466 URL: https://issues.apache.org/jira/browse/COUCHDB-466 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.10 Reporter: Benoit Chesneau Priority: Blocker Fix For: 0.10 Attachments: x_forwarded_host.diff Currently oauth doesn't work behind a reverse proxy because signature is based on Host. Reverse proxy like apache, lighttpd pass to the proxied server some header that help him to know which host is forwared. Apache send X-Forwarded-For, Lighttpd X-Host, Patch attached fix this issue by testing if a custom forwarded host header is present and use it as Host. If it isn't present it will use Host header of fallback on socket detection like it is currently. All tests pass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Security implications of erlview
Now that erlang views are included in couchdb - even though the .ini file
doesn't enable them by default and the server is bound to 127.0.0.1 - it
might be worth adding a red flag about the security issues. As far as I can
see there is no sandboxing, e.g. the following runs quite happily:
$ curl -X POST -d '{language:erlang,map:fun({Doc}) - F = fun(Port) -
receive {Port, {data, Data}} - Emit(null, list_to_binary(Data)) end end,
F(open_port({spawn, \/bin/ls /tmp\}, [stream])) end.}'
'http://127.0.0.1:5984/zzz/_temp_view'
So in effect, access to _temp_view is the same as giving shell access to the
box as the couchdb user. So it's necessary at least to configure access
controls to prevent non-admin users from accessing _temp_view and updating
_design docs.
Regards,
Brian.
[jira] Commented: (COUCHDB-471) make distcheck fails
[ https://issues.apache.org/jira/browse/COUCHDB-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744555#action_12744555 ] Paul Joseph Davis commented on COUCHDB-471: --- Noah, the thing with $(top_srcdir) is that if you do a VPATH build then you end up creating the tmp directory structure in the src tree and not the build tree. make distcheck adjusts file permissions to prevent writing by the build process and this step fails. So is it possible to use $(top_builddir) or just prevent make dev from running durring distcheck? make distcheck fails Key: COUCHDB-471 URL: https://issues.apache.org/jira/browse/COUCHDB-471 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 0.10 Environment: Mac OS X Reporter: Jan Lehnardt Assignee: Paul Joseph Davis Priority: Critical Fix For: 0.10 Attachments: couchdb-licence_skip.patch make[2]: *** No rule to make target `local.ini', needed by `distdir'. Stop. make[1]: *** [distdir] Error 1 make: *** [distdir] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-465) Produce sequential, but unique, document id's
[ https://issues.apache.org/jira/browse/COUCHDB-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-465: -- Attachment: uuid_generator.patch changed [uuid] config to [uuid_generation] changed sequence to sequential made sequential the default fixed rollover to use all bits of counter suffix Produce sequential, but unique, document id's - Key: COUCHDB-465 URL: https://issues.apache.org/jira/browse/COUCHDB-465 Project: CouchDB Issue Type: Improvement Reporter: Robert Newson Attachments: uuid_generator.patch, uuid_generator.patch, uuid_generator.patch Currently, if the client does not specify an id (POST'ing a single document or using _bulk_docs) a random 16 byte value is created. This kind of key is particularly brutal on b+tree updates and the append-only nature of couchdb files. Attached is a patch to change this to a two-part identifier. The first part is a random 12 byte value and the remainder is a counter. The random prefix is rerandomized when the counter reaches its maximum. The rollover in the patch is at 16 million but can obviously be changed. The upshot is that the b+tree is updated in a better fashion, which should lead to performance benefits. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-465) Produce sequential, but unique, document id's
[ https://issues.apache.org/jira/browse/COUCHDB-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-465: -- Attachment: (was: uuid_generator.patch) Produce sequential, but unique, document id's - Key: COUCHDB-465 URL: https://issues.apache.org/jira/browse/COUCHDB-465 Project: CouchDB Issue Type: Improvement Reporter: Robert Newson Attachments: uuid_generator.patch Currently, if the client does not specify an id (POST'ing a single document or using _bulk_docs) a random 16 byte value is created. This kind of key is particularly brutal on b+tree updates and the append-only nature of couchdb files. Attached is a patch to change this to a two-part identifier. The first part is a random 12 byte value and the remainder is a counter. The random prefix is rerandomized when the counter reaches its maximum. The rollover in the patch is at 16 million but can obviously be changed. The upshot is that the b+tree is updated in a better fashion, which should lead to performance benefits. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-465) Produce sequential, but unique, document id's
[ https://issues.apache.org/jira/browse/COUCHDB-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-465: -- Attachment: (was: uuid_generator.patch) Produce sequential, but unique, document id's - Key: COUCHDB-465 URL: https://issues.apache.org/jira/browse/COUCHDB-465 Project: CouchDB Issue Type: Improvement Reporter: Robert Newson Attachments: uuid_generator.patch Currently, if the client does not specify an id (POST'ing a single document or using _bulk_docs) a random 16 byte value is created. This kind of key is particularly brutal on b+tree updates and the append-only nature of couchdb files. Attached is a patch to change this to a two-part identifier. The first part is a random 12 byte value and the remainder is a counter. The random prefix is rerandomized when the counter reaches its maximum. The rollover in the patch is at 16 million but can obviously be changed. The upshot is that the b+tree is updated in a better fashion, which should lead to performance benefits. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-237) Futon page for creating test cases.
[ https://issues.apache.org/jira/browse/COUCHDB-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744566#action_12744566 ] Simon Thulbourn commented on COUCHDB-237: - I presume you mean in trunk? I don't see it on my 0.9.1 release. Futon page for creating test cases. --- Key: COUCHDB-237 URL: https://issues.apache.org/jira/browse/COUCHDB-237 Project: CouchDB Issue Type: New Feature Components: Administration Console, Test Suite Reporter: Paul Joseph Davis Assignee: Paul Joseph Davis Fix For: 0.10 It'd help to have a Futon page that allowed us to write test cases directly in JavaScript. I'm not thinking of anything really fancy beyond a text box on a page that has couch.js and couch_test_runner.js loaded. Integration with a paste service for pasting links into IRC or email would also be awesome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-245) Couch uses the erlang stdlib module regexp, which is deprecated and set to be removed. It should use the module re instead.
[ https://issues.apache.org/jira/browse/COUCHDB-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744567#action_12744567 ] Curt Arnold commented on COUCHDB-245: - The regexp calls in Mochweb were replaced with re calls on June 25, 2009, rev 102. Should the bundled mochiweb be updated to remove all the deprecation warnings? Couch uses the erlang stdlib module regexp, which is deprecated and set to be removed. It should use the module re instead. --- Key: COUCHDB-245 URL: https://issues.apache.org/jira/browse/COUCHDB-245 Project: CouchDB Issue Type: Bug Components: Infrastructure Affects Versions: 0.7.2, 0.8, 0.8.1, 0.9 Environment: regexp is set to be removed from stdlib when R15 is released. Reporter: alisdair sullivan Assignee: Adam Kocoloski Priority: Blocker Fix For: 0.10 Attachments: couch_mochi_re_patch, couch_re_patch, couch_re_patch_2 Original Estimate: 2h Remaining Estimate: 2h Couch uses the erlang stdlib module regexp, which is deprecated and set to be removed. It should use the module re instead. re is not a drop in replacement for regexp, it operates on and returns binary strings instead of native strings. Affects files couch_config.erl, couch_config_writer.erl, couch_httpd.erl, couch_httpd_server.erl, couch_log.erl and couch_server.erl. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-237) Futon page for creating test cases.
[ https://issues.apache.org/jira/browse/COUCHDB-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744575#action_12744575 ] Paul Joseph Davis commented on COUCHDB-237: --- Yep. It's only been in for a couple weeks. Futon page for creating test cases. --- Key: COUCHDB-237 URL: https://issues.apache.org/jira/browse/COUCHDB-237 Project: CouchDB Issue Type: New Feature Components: Administration Console, Test Suite Reporter: Paul Joseph Davis Assignee: Paul Joseph Davis Fix For: 0.10 It'd help to have a Futon page that allowed us to write test cases directly in JavaScript. I'm not thinking of anything really fancy beyond a text box on a page that has couch.js and couch_test_runner.js loaded. Integration with a paste service for pasting links into IRC or email would also be awesome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-474) Upgrade MochiWeb dependency
Upgrade MochiWeb dependency --- Key: COUCHDB-474 URL: https://issues.apache.org/jira/browse/COUCHDB-474 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.10 Reporter: Paul Joseph Davis Assignee: Paul Joseph Davis Priority: Blocker Upgrade the MochiWeb dependency to the latest version in the google code repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-466) couchdb oauth doesn't work behind reverse proxy
[ https://issues.apache.org/jira/browse/COUCHDB-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Chesneau updated COUCHDB-466: Attachment: forwarded_for2.patch patch with typo fixed and js test. couchdb oauth doesn't work behind reverse proxy --- Key: COUCHDB-466 URL: https://issues.apache.org/jira/browse/COUCHDB-466 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.10 Reporter: Benoit Chesneau Priority: Blocker Fix For: 0.10 Attachments: forwarded_for2.patch, x_forwarded_host.diff Currently oauth doesn't work behind a reverse proxy because signature is based on Host. Reverse proxy like apache, lighttpd pass to the proxied server some header that help him to know which host is forwared. Apache send X-Forwarded-For, Lighttpd X-Host, Patch attached fix this issue by testing if a custom forwarded host header is present and use it as Host. If it isn't present it will use Host header of fallback on socket detection like it is currently. All tests pass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-466) couchdb oauth doesn't work behind reverse proxy
[ https://issues.apache.org/jira/browse/COUCHDB-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt closed COUCHDB-466. Resolution: Fixed fixed the tests: - wrapped config changes in run_on_modified_server - wrap lines at 80 chars - use TEquals() instead of T() Applied in r805500. couchdb oauth doesn't work behind reverse proxy --- Key: COUCHDB-466 URL: https://issues.apache.org/jira/browse/COUCHDB-466 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.10 Reporter: Benoit Chesneau Priority: Blocker Fix For: 0.10 Attachments: forwarded_for2.patch, x_forwarded_host.diff Currently oauth doesn't work behind a reverse proxy because signature is based on Host. Reverse proxy like apache, lighttpd pass to the proxied server some header that help him to know which host is forwared. Apache send X-Forwarded-For, Lighttpd X-Host, Patch attached fix this issue by testing if a custom forwarded host header is present and use it as Host. If it isn't present it will use Host header of fallback on socket detection like it is currently. All tests pass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Cryptography in CouchDB
On Aug 17, 2009, at 10:16 PM, Curt Arnold wrote: On Aug 17, 2009, at 6:45 PM, Damien Katz wrote: I don't think it's necessary as we aren't encrypting anything. We do use the crypto library, but only for generating random UUIDs. -Damien Probably should have used suspect or concerned or something more speculative. Noticing that CouchDB would not start on an Erlang runtime without openssl was a bit jarring. OAuth would also seem to be have a significant likelihood of incorporating encryption. Those two facts seemed to warrant a message. The whole export license stuff is an quagmire that I've taken pains to avoid. Definitely think that you should check with legal-discuss if you have any questions. erlang_oauth has a module named oauth_rsa_sha1 which makes me suspect that it would need an export declaration. The following code snippet from couch_http_oauth.erl consumer_lookup(Key, MethodStr) - SignatureMethod = case MethodStr of PLAINTEXT - plaintext; HMAC-SHA1 - hmac_sha1; %RSA-SHA1 - rsa_sha1; _Else - undefined appears to be at aware of specific encryption method. I also ran into this little snippet in couch_util.erl: %%% Purpose : Base 64 encoding and decoding. %%% Copied from ssl_base_64 to avoid using the %%% erlang ssl library If there is a required dependency on ssl elsewhere, the duplicated code probably should be eliminated. Also, the license notice doesn't give me much confidence. FYI: Encryption notice for Erlang ssl: http://erlang.org/doc/apps/ssl/index.html My wild guess is that the previous CouchDB releases did not need an export or cryptography notice if all they did was use the random number generator from the SSL module.erlang_oauth and couch_http_oauth seem to be aware of cryptographic methods which my reading means that they require some action, but exactly what I'm uncertain. I disagree. We don't encrypt anything and as far as I know neither does any of the Auth stuff, which just uses cryptographic strength hashes, not encryption itself. -Damien
[SPAM] CouchDB Training in Boston, MA Sept. 10th/11th
Hi Couchers, sorry for the spam :) — We, couch.io, are running a CouchDB training course* in Boston, MA on September 10th 11th right before jQuery Conference** and The Ajax Experience***. * CouchDB Training: http://couchio.com/courses ** http://events.jquery.com/jquery-conference-2009/ *** http://ajaxexperience.techtarget.com/ This is a great chance to learn all about CouchDB while meeting the greatest minds in the Ajax world. -- If you feel this posting is inappropriate for this audience, please let me know. Cheers Jan --
Re: [SPAM] CouchDB Training in Boston, MA Sept. 10th/11th
On Tue, Aug 18, 2009 at 07:53:43PM +0200, Jan Lehnardt wrote: If you feel this posting is inappropriate for this audience, please let me know. I am +1 on posting details about CouchDB related events, for profit or not. General technology and database conferences, or items, not so much. Best, -- Noah Slater, http://tumbolia.org/nslater
Re: [SPAM] CouchDB Training in Boston, MA Sept. 10th/11th
I am +1 on posting details about CouchDB related events, for profit or not. General technology and database conferences, or items, not so much. I am +1 on Noah's distinction for what's kosher.
Open Source .NET API
I am working on an open source .NET API for CouchDB called Ottoman. The project has gotten far enough now, that I thought I should mention it to you guys. The project's source is located here: http://github.com/sinesignal/ottoman/tree/master I wasn't sure if I should post this on the user's list or the dev list. I am sorry if I posted it on the wrong list. Thanks, Dale
Re: Open Source .NET API
I am a coucher by night who spends his days writing .NET code. Is there an area of your API that you could use help with. I'd love to contribute. -Justin On Tue, Aug 18, 2009 at 9:30 AM, Dale Ragandale.ra...@sinesignal.com wrote: I am working on an open source .NET API for CouchDB called Ottoman. The project has gotten far enough now, that I thought I should mention it to you guys. The project's source is located here: http://github.com/sinesignal/ottoman/tree/master I wasn't sure if I should post this on the user's list or the dev list. I am sorry if I posted it on the wrong list. Thanks, Dale
Re: continuous replication API discussion
On 18 Aug 2009, at 10:44, Simon Metson wrote: I wouldn't completely replace the current .ini configuration files with a database -- I think there's real value in being able to change some settings without the server running. Agreed, there are certain classes of configuration data you'd want in a database and others you'd want in an ini. Whether you want to easily replicate it is probably a good guide where it should go... We can't have all settings in the DB. It is possible to render CouchDB unusable by changing some config values and then you'd have no way to fix it again. we need the ini files for that. I see a database for jobs in CouchDB though. Something that continuous replication jobs can be stored in, but I can also see jobs that keep view indexes up to date asynchronously so apps can run on stale=ok only. But maybe we don't even need that for 0.10? I'd be happy to ship with the ability to trigger continuous replication on server startup that doesn't survive restarts and leave that to the user for the time being until we figured out a good way to do the config db. Cheers Jan --
Re: continuous replication API discussion
On Aug 18, 2009, at 7:42 PM, Jan Lehnardt wrote: But maybe we don't even need that for 0.10? I'd be happy to ship with the ability to trigger continuous replication on server startup that doesn't survive restarts and leave that to the user for the time being until we figured out a good way to do the config db. I think that's best at this point. POSTing to _replicate with a continuous:true field in the body will generate a 202 Accepted response that included a _local_id field in the body. The downside (as Paul pointed out online) is that the only way to cancel a continuous replication triggered this way is to restart the server. Adam
