[jira] Commented: (COUCHDB-642) Support rev in PUT URL
[
https://issues.apache.org/jira/browse/COUCHDB-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899777#action_12899777
]
Brian Candler commented on COUCHDB-642:
---
I'd prefer that the rev in the URL overrode any value in the document, because:
(1) This is what happens for _id. That is, I believe that any _id within the
document is ignored in a PUT, in favour of the id in the URL.
(2) I think it's more "relaxed" if I can specify the _id and _rev in the URL,
then I can forget about what's in the document. If I were forced to erase the
value in the document, or make it equal to what's in the URL, then I'd just put
it in the document in the first place.
> Support rev in PUT URL
> --
>
> Key: COUCHDB-642
> URL: https://issues.apache.org/jira/browse/COUCHDB-642
> Project: CouchDB
> Issue Type: New Feature
> Components: HTTP Interface
> Environment: trunk 08 Feb 2010
>Reporter: Brian Candler
>Priority: Minor
> Attachments: 0001-Allow-for-the-current-revision-number-to-be.patch
>
>
> A DELETE request lets you append ?rev= to the URL. But this doesn't work
> with a PUT request; you have to put the _rev in the body instead (even though
> the _id is taken from the URL path)
> $ curl -X PUT -d "{}"
> http://brianadmin:brianad...@127.0.0.1:5984/briantest/foo
> {"ok":true,"id":"foo","rev":"1-967a00dff5e02add41819138abb3284d"}
> $ curl -X PUT -d "{}"
> http://brianadmin:brianad...@127.0.0.1:5984/briantest/foo?rev=1-967a00dff5e02add41819138abb3284d
> {"error":"conflict","reason":"Document update conflict."}
> $ curl -X PUT -d '{"_rev":"1-967a00dff5e02add41819138abb3284d"}'
> http://brianadmin:brianad...@127.0.0.1:5984/briantest/foo
> {"ok":true,"id":"foo","rev":"2-7051cbe5c8faecd085a3fa619e6e6337"}
> Allowing ?rev in the URL would make PUT and DELETE more consistent, and would
> allow you to replace an existing JSON doc with another one without having to
> merge the _rev into it 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-684) Futon security dialog overwrites other properties of security doc
[ https://issues.apache.org/jira/browse/COUCHDB-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842377#action_12842377 ] Brian Candler commented on COUCHDB-684: --- > 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. If you were to store a random _rev in the _security object itself, then you could implement concurrency control for _security without too much work AFAICS. It would only be half-baked, but since _security doesn't replicate it wouldn't matter. Then if you're going to store/update _rev, you might as well set _id:"_security" at the same time. That is, you wouldn't be faking up the API, so much as adding some fixed data into _security to make it look more like a doc. > 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-661) _all_dbs should list only the DBs accessible to the user
[ https://issues.apache.org/jira/browse/COUCHDB-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836454#action_12836454 ] Brian Candler commented on COUCHDB-661: --- Looks like a serious DoS to me, with "only" 7500 databases. If _all_dbs won't scale, then I think it should be for admins only (ideally with startkey/limit like _all_docs for efficient pagination, but that's a different issue) Or perhaps it should be possible to replace _all_dbs with a view in a 'real' database for non-admins. e.g. occasionally you could copy all the _security objects into another database, and generate a view with keys like emit(['name',name],db) emit(['role',role],db) for efficient querying. (IMHO this is another reason why _security objects should be real docs: so that you can follow a _changes feed on them) > _all_dbs should list only the DBs accessible to the user > > > Key: COUCHDB-661 > URL: https://issues.apache.org/jira/browse/COUCHDB-661 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 0.11 > Environment: trunk / 0.11 >Reporter: Filipe Manana > Fix For: 0.11 > > Attachments: couchdb-_all_dbs-auth-2.patch, > couchdb-_all_dbs-auth.patch > > > As discussed in the auth roadmap mail, sent by Chris to @dev, the _all_dbs > URI should only list the DBs that are accessible to the user. > The following patch is a naive solution. It doesn't scale for CouchDB servers > with millions of DBs. Regarding this scaling detail, I'll discuss soon in the > @dev mailing list some ideas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-642) Support rev in PUT URL
Support rev in PUT URL
--
Key: COUCHDB-642
URL: https://issues.apache.org/jira/browse/COUCHDB-642
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Environment: trunk 08 Feb 2010
Reporter: Brian Candler
Priority: Minor
A DELETE request lets you append ?rev= to the URL. But this doesn't work
with a PUT request; you have to put the _rev in the body instead (even though
the _id is taken from the URL path)
$ curl -X PUT -d "{}" http://brianadmin:brianad...@127.0.0.1:5984/briantest/foo
{"ok":true,"id":"foo","rev":"1-967a00dff5e02add41819138abb3284d"}
$ curl -X PUT -d "{}"
http://brianadmin:brianad...@127.0.0.1:5984/briantest/foo?rev=1-967a00dff5e02add41819138abb3284d
{"error":"conflict","reason":"Document update conflict."}
$ curl -X PUT -d '{"_rev":"1-967a00dff5e02add41819138abb3284d"}'
http://brianadmin:brianad...@127.0.0.1:5984/briantest/foo
{"ok":true,"id":"foo","rev":"2-7051cbe5c8faecd085a3fa619e6e6337"}
Allowing ?rev in the URL would make PUT and DELETE more consistent, and would
allow you to replace an existing JSON doc with another one without having to
merge the _rev into it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COUCHDB-313) '$' in database name confuses behaviour of %2F in design doc ID
[
https://issues.apache.org/jira/browse/COUCHDB-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Candler resolved COUCHDB-313.
---
Resolution: Fixed
Yes, I concur.
> '$' in database name confuses behaviour of %2F in design doc ID
> ---
>
> Key: COUCHDB-313
> URL: https://issues.apache.org/jira/browse/COUCHDB-313
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.9
> Environment: svn r761188
> Ubuntu Hardy + Erlang 12B3 from Intrepid
>Reporter: Brian Candler
>Priority: Minor
>
> Normally, if you use %2F to separate _design from the rest of the URL, you
> get a 301 redirect:
> $ curl -X PUT http://127.0.0.1:5984/mydb
> {"ok":true}
> $ curl -X PUT -d"{}" http://127.0.0.1:5984/mydb/_design/test
> {"ok":true,"id":"_design/test","rev":"1-481559718"}
> $ curl -v http://127.0.0.1:5984/mydb/_design%2Ftest
> ...
> < HTTP/1.1 301 Moved Permanently
> < Server: CouchDB/0.9.0 (Erlang OTP/R12B)
> < Location: http://127.0.0.1:5984/mydb/_design/test
> However this logic is broken if you use a database which has a '$' in the
> name: you get a 'badmatch' erlang error.
> $ curl -X PUT 'http://127.0.0.1:5984/my$db'
> {"ok":true}
> $ curl -X PUT -d'{}' 'http://127.0.0.1:5984/my$db/_design/test'
> {"ok":true,"id":"_design/test","rev":"1-4187139805"}
> $ curl 'http://127.0.0.1:5984/my$db/_design/test'
> {"_id":"_design/test","_rev":"1-4187139805"}
> $ curl 'http://127.0.0.1:5984/my$db/_design%2Ftest'
> {"error":"badmatch","reason":"{ok,[\"/my$db/\",\"test\"]}"}
> $ is allowed in a database name according to the wiki (as long as it's not
> the first character), and otherwise appears to work OK. I have not tried
> other 'unusual' characters.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-412) CouchDB fails to start when log file is a pipe
[ https://issues.apache.org/jira/browse/COUCHDB-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802805#action_12802805 ] Brian Candler commented on COUCHDB-412: --- I think this should be made a general facility to log via an external program: i.e. don't hardcoded the path to pipe_wrapper.sh, or the fact that it requires a filename argument for the log destination. This would then be comparable to the corresponding feature in Apache httpd: CustomLog "|/path/to/program" ... It would let you do lots of cool things: e.g. log to syslog or log via HTTP to another couchdb server, without having to launch another process which tails a pipe. > CouchDB fails to start when log file is a pipe > -- > > Key: COUCHDB-412 > URL: https://issues.apache.org/jira/browse/COUCHDB-412 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.9 > Environment: CentOS x86_64 >Reporter: Enda Farrell > Attachments: COUCHDB_412_01.patch, pipe_wrapper.sh > > > I have an 0.9 CouchDB. When the local.ini file's [log] file is actually a > pipe (with a known to be running consumer) rather than a file, CouchDB fails > to start. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-626) [PATCH] test for _update with base64
[ https://issues.apache.org/jira/browse/COUCHDB-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Candler updated COUCHDB-626: -- Attachment: use-stringfun.diff test-update-base64.diff > [PATCH] test for _update with base64 > > > Key: COUCHDB-626 > URL: https://issues.apache.org/jira/browse/COUCHDB-626 > Project: CouchDB > Issue Type: Improvement >Reporter: Brian Candler >Priority: Trivial > Attachments: test-update-base64.diff, use-stringfun.diff > > > The first attached patch adds a (passing) test for base64 output from _update > functions. > The second patch tidies up slightly by using stringFun() in a couple of > places where it currently isn't. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-626) [PATCH] test for _update with base64
[PATCH] test for _update with base64 Key: COUCHDB-626 URL: https://issues.apache.org/jira/browse/COUCHDB-626 Project: CouchDB Issue Type: Improvement Reporter: Brian Candler Priority: Trivial The first attached patch adds a (passing) test for base64 output from _update functions. The second patch tidies up slightly by using stringFun() in a couple of places where it currently isn't. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-624) Bulk import of non-JSON formats
Bulk import of non-JSON formats --- Key: COUCHDB-624 URL: https://issues.apache.org/jira/browse/COUCHDB-624 Project: CouchDB Issue Type: New Feature Components: HTTP Interface Reporter: Brian Candler Priority: Minor The _list feature can be used to perform bulk exports in non-JSON formats (e.g. XML, CSV) There does not appear to be a corresponding function for bulk imports. _update can parse alien formats, but acts on a single document only. I think we need something like _update but which can emit a stream of documents like _list, or return an array of docs like _bulk_docs uses. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-620) Generating views is extremely slow - makes CouchDB hard to use with non-trivial number of docs
[ https://issues.apache.org/jira/browse/COUCHDB-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800145#action_12800145 ] Brian Candler commented on COUCHDB-620: --- >The error reporting issue is that if you've got four docs in the pipeline, and >the process dies, then its hard to tell which document caused the error. Well, I guess it is on the 'push' side. But if you update your pointers on the 'pull' side, and you've had two documents back, then the error must be in the third. > And generally retrying will just cause another error. If the view server *crashes* when fed document X, then I think document X should be retried - i.e. this was probably an intermittent server error. But if processing document X raised an *exception* (i.e. map function cannot handle the content) then I'd have thought that couchjs should catch, serialise and return the exception. That would allow the document to be skipped cleanly. > Generating views is extremely slow - makes CouchDB hard to use with > non-trivial number of docs > -- > > Key: COUCHDB-620 > URL: https://issues.apache.org/jira/browse/COUCHDB-620 > Project: CouchDB > Issue Type: Improvement > Components: Infrastructure >Affects Versions: 0.10 > Environment: Ubuntu 9.10 64 bit, CouchDB 0.10 >Reporter: Roger Binns >Assignee: Damien Katz > Attachments: pipelining.jpg > > > Generating views is extremely slow. For example adding 10 million documents > takes less than 10 minutes but generating some simple views on the same docs > takes over 4 hours. > Using top you can see that CouchDB (erlang) and couchjs between them cannot > even saturate a single CPU let alone the I/O system. Under ideal conditions > performance should be limited by cpu, disk or memory. This implies that the > processes are doing simple things in lockstep accumulating latencies in each > process as well as the communication between them which when multiplied by > the number of documents can amount to a lot. > Some suggestions: > * Run as many couchjs instances as there are processor cores and scatter work > amongst them > * Have some sort of pipelining in the erlang so that the moment the first > byte of response is received from couchjs the data is sent for the next > request (the JSON conversion, HTTP headers etc should all have been assembled > already) to reduce latencies. Do whatever is most similar in couchjs (eg use > separate threads to read requests, process them and write responses). > * Use the equivalent of HTTP pipelining when talking to couchjs so that it > always has a doc ready to work on rather than having to transmit an entire > response and then wait for erlang to think and provide an entire new request > A simple test of success is to have a database with a million or so documents > with a trivial view and have view creation max out the CPU,. memory or disk. > Some things in CouchDB make this a particularly nasty problem. View data is > not replicated so replicating documents can lead the view data by a large > margin on the recipient database. This can lead to inconsistencies. You > also can't expect users to then wait minutes (or hours) for a request to > complete because the view generation got that far behind. (My own plans now > are to not use replication and instead create the database file on another > couchdb instance and then rsync the binary database file over instead!) > Although stale=ok is available, you still have no idea if the response will > be quick or take however long view generation does. (Sure I could add some > sort of timeout and complicate the code but then what value do I pick? If I > have a user waiting I want an answer ASAP or I have to give them some > horrible error message. Taking a long wait and then giving a timeout is even > worse!) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-622) erlview sandboxing via parse transform
erlview sandboxing via parse transform -- Key: COUCHDB-622 URL: https://issues.apache.org/jira/browse/COUCHDB-622 Project: CouchDB Issue Type: Improvement Reporter: Brian Candler Priority: Minor I'm just adding this ticket so I don't forget about it. It's possible to improve the safety of the native erlang view server, just by doing a simple walk of the parsed abstract form. I think all we need to do is forbid calls to functions in all external modules m:f(), except for whitelisted modules (e.g. io_lib, lists) or specific functions. We also need a whitelist of BIFs. Some care may be needed for imported functions - check if they are already expanded to m:f() in the abstract form, or remain as f(). My main concern is preventing things like os:cmd(). There are also many possible DoS attacks, like atom exhaustion or spawning infinite numbers of processes. However, most view definitions aren't going to need spawn() or list_to_atom(). A configurable whitelist could be very tight by default, but still allow admins to allow any specific functions they need. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-620) Generating views is extremely slow - makes CouchDB hard to use with non-trivial number of docs
[ https://issues.apache.org/jira/browse/COUCHDB-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799586#action_12799586 ] Brian Candler commented on COUCHDB-620: --- Like Paul says: I am not proposing any change to the couchjs protocol, nor to allow out-of-order returning of responses from couchjs. Just this: that the core takes the next 3 (say) documents to be processed, stuffs them down the socket to couchjs, then sends another one each time a whole document response is received. The couchjs view server is completely unaware of this, since it runs lock-step (read a request, emit response, read request, emit response). It's just that when it next comes to read a request, there will be one waiting for it already. The same as HTTP pipelining, in other words. I don't see any particular problem with error handling. If you've not received a complete response for document X, then you don't update the view pointer so you'll try again next time. > Generating views is extremely slow - makes CouchDB hard to use with > non-trivial number of docs > -- > > Key: COUCHDB-620 > URL: https://issues.apache.org/jira/browse/COUCHDB-620 > Project: CouchDB > Issue Type: Improvement > Components: Infrastructure >Affects Versions: 0.10 > Environment: Ubuntu 9.10 64 bit, CouchDB 0.10 >Reporter: Roger Binns >Assignee: Damien Katz > Attachments: pipelining.jpg > > > Generating views is extremely slow. For example adding 10 million documents > takes less than 10 minutes but generating some simple views on the same docs > takes over 4 hours. > Using top you can see that CouchDB (erlang) and couchjs between them cannot > even saturate a single CPU let alone the I/O system. Under ideal conditions > performance should be limited by cpu, disk or memory. This implies that the > processes are doing simple things in lockstep accumulating latencies in each > process as well as the communication between them which when multiplied by > the number of documents can amount to a lot. > Some suggestions: > * Run as many couchjs instances as there are processor cores and scatter work > amongst them > * Have some sort of pipelining in the erlang so that the moment the first > byte of response is received from couchjs the data is sent for the next > request (the JSON conversion, HTTP headers etc should all have been assembled > already) to reduce latencies. Do whatever is most similar in couchjs (eg use > separate threads to read requests, process them and write responses). > * Use the equivalent of HTTP pipelining when talking to couchjs so that it > always has a doc ready to work on rather than having to transmit an entire > response and then wait for erlang to think and provide an entire new request > A simple test of success is to have a database with a million or so documents > with a trivial view and have view creation max out the CPU,. memory or disk. > Some things in CouchDB make this a particularly nasty problem. View data is > not replicated so replicating documents can lead the view data by a large > margin on the recipient database. This can lead to inconsistencies. You > also can't expect users to then wait minutes (or hours) for a request to > complete because the view generation got that far behind. (My own plans now > are to not use replication and instead create the database file on another > couchdb instance and then rsync the binary database file over instead!) > Although stale=ok is available, you still have no idea if the response will > be quick or take however long view generation does. (Sure I could add some > sort of timeout and complicate the code but then what value do I pick? If I > have a user waiting I want an answer ASAP or I have to give them some > horrible error message. Taking a long wait and then giving a timeout is even > worse!) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-620) Generating views is extremely slow - makes CouchDB hard to use with non-trivial number of docs
[ https://issues.apache.org/jira/browse/COUCHDB-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799129#action_12799129 ] Brian Candler commented on COUCHDB-620: --- "the CouchDB process took between 70% and 130% of a CPU, usually in the 110% range" That looks like one CPU fully used for CouchDB (with afterburners to get to 110% :-) "The couchjs process was hovering around 25% of a CPU" - which suggests that couchjs is waiting on couchdb to issue it with more work, so parallelising couchjs wouldn't help. For comparison, have you tried the erlang view server? That would eliminate JSON serialisation/deserialisation overhead, plus much of the message-passing overhead. It would be very useful to have this comparison on your large dataset. If measurement shows that the json serialisation overhead is large, maybe there's a fairly simple improvement: in couch_os_process.erl, make writejson and readjson execute in separate erlang processes, so they can execute on another core. You would need to pipeline requests to the view server to get the full benefit though. > Generating views is extremely slow - makes CouchDB hard to use with > non-trivial number of docs > -- > > Key: COUCHDB-620 > URL: https://issues.apache.org/jira/browse/COUCHDB-620 > Project: CouchDB > Issue Type: Improvement > Components: Infrastructure >Affects Versions: 0.10 > Environment: Ubuntu 9.10 64 bit, CouchDB 0.10 >Reporter: Roger Binns >Assignee: Damien Katz > > Generating views is extremely slow. For example adding 10 million documents > takes less than 10 minutes but generating some simple views on the same docs > takes over 4 hours. > Using top you can see that CouchDB (erlang) and couchjs between them cannot > even saturate a single CPU let alone the I/O system. Under ideal conditions > performance should be limited by cpu, disk or memory. This implies that the > processes are doing simple things in lockstep accumulating latencies in each > process as well as the communication between them which when multiplied by > the number of documents can amount to a lot. > Some suggestions: > * Run as many couchjs instances as there are processor cores and scatter work > amongst them > * Have some sort of pipelining in the erlang so that the moment the first > byte of response is received from couchjs the data is sent for the next > request (the JSON conversion, HTTP headers etc should all have been assembled > already) to reduce latencies. Do whatever is most similar in couchjs (eg use > separate threads to read requests, process them and write responses). > * Use the equivalent of HTTP pipelining when talking to couchjs so that it > always has a doc ready to work on rather than having to transmit an entire > response and then wait for erlang to think and provide an entire new request > A simple test of success is to have a database with a million or so documents > with a trivial view and have view creation max out the CPU,. memory or disk. > Some things in CouchDB make this a particularly nasty problem. View data is > not replicated so replicating documents can lead the view data by a large > margin on the recipient database. This can lead to inconsistencies. You > also can't expect users to then wait minutes (or hours) for a request to > complete because the view generation got that far behind. (My own plans now > are to not use replication and instead create the database file on another > couchdb instance and then rsync the binary database file over instead!) > Although stale=ok is available, you still have no idea if the response will > be quick or take however long view generation does. (Sure I could add some > sort of timeout and complicate the code but then what value do I pick? If I > have a user waiting I want an answer ASAP or I have to give them some > horrible error message. Taking a long wait and then giving a timeout is even > worse!) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-619) Don't keep looping when couchjs fails to start
[
https://issues.apache.org/jira/browse/COUCHDB-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798390#action_12798390
]
Brian Candler commented on COUCHDB-619:
---
Or just config the query server as couchjs without main.js
$ /usr/local/bin/couchjs
You must specify a FILE.
Try `couchjs -h' for more information.
$ echo $?
1
> Don't keep looping when couchjs fails to start
> --
>
> Key: COUCHDB-619
> URL: https://issues.apache.org/jira/browse/COUCHDB-619
> Project: CouchDB
> Issue Type: Improvement
> Environment: couchdb trunk
> ubuntu karmic x64
>Reporter: Brian Candler
>Priority: Minor
>
> Ubuntu just sent out a new version of xulrunner (1.9.1.6 -> 1.9.1.7)
> As a result, couchjs no longer worked, as it was linked against 1.9.1.6 in a
> specific directory, and that directory had been removed.
> However it took me a bit to work out what was going on. When I ran the test
> suite, it just got stuck at "> Basic > Running...". A curl
> http://127.0.0.1:5984/ was fine, but any attempt to make a query just hung.
> Eventually I found that loads of these were being logged:
> [Sat, 09 Jan 2010 12:07:43 GMT] [error] [<0.129.0>] OS Process Error
> <0.1918.0> :: {os_process_error,{exit_status,127}}
> [Sat, 09 Jan 2010 12:07:43 GMT] [error] [<0.129.0>] OS Process Error
> <0.1921.0> :: {os_process_error,{exit_status,127}}
> [Sat, 09 Jan 2010 12:07:43 GMT] [error] [<0.129.0>] OS Process Error
> <0.1924.0> :: {os_process_error,{exit_status,127}}
> [Sat, 09 Jan 2010 12:07:43 GMT] [error] [<0.129.0>] OS Process Error
> <0.1927.0> :: {os_process_error,{exit_status,127}}
> ...
> (over 3MB by the time I'd realised).
> I wonder if couchdb could handle this a bit more gracefully? For example, if
> couchjs starts and dies before even a single request has been sent to it,
> then disable it for a few minutes and/or log a more specific error message?
> Returning an error to the view client would be good too, rather than hanging
> waiting for a view update which can never complete. Just a thought.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (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
]
Brian Candler updated COUCHDB-617:
--
Attachment: couchdb-test-json.diff
Here is a simple test case for the JSON round-trip
> 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
> 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] Created: (COUCHDB-619) Don't keep looping when couchjs fails to start
Don't keep looping when couchjs fails to start
--
Key: COUCHDB-619
URL: https://issues.apache.org/jira/browse/COUCHDB-619
Project: CouchDB
Issue Type: Improvement
Environment: couchdb trunk
ubuntu karmic x64
Reporter: Brian Candler
Priority: Minor
Ubuntu just sent out a new version of xulrunner (1.9.1.6 -> 1.9.1.7)
As a result, couchjs no longer worked, as it was linked against 1.9.1.6 in a
specific directory, and that directory had been removed.
However it took me a bit to work out what was going on. When I ran the test
suite, it just got stuck at "> Basic > Running...". A curl
http://127.0.0.1:5984/ was fine, but any attempt to make a query just hung.
Eventually I found that loads of these were being logged:
[Sat, 09 Jan 2010 12:07:43 GMT] [error] [<0.129.0>] OS Process Error <0.1918.0>
:: {os_process_error,{exit_status,127}}
[Sat, 09 Jan 2010 12:07:43 GMT] [error] [<0.129.0>] OS Process Error <0.1921.0>
:: {os_process_error,{exit_status,127}}
[Sat, 09 Jan 2010 12:07:43 GMT] [error] [<0.129.0>] OS Process Error <0.1924.0>
:: {os_process_error,{exit_status,127}}
[Sat, 09 Jan 2010 12:07:43 GMT] [error] [<0.129.0>] OS Process Error <0.1927.0>
:: {os_process_error,{exit_status,127}}
...
(over 3MB by the time I'd realised).
I wonder if couchdb could handle this a bit more gracefully? For example, if
couchjs starts and dies before even a single request has been sent to it, then
disable it for a few minutes and/or log a more specific error message?
Returning an error to the view client would be good too, rather than hanging
waiting for a view update which can never complete. Just a thought.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-617) Large integers being turned into floats
[
https://issues.apache.org/jira/browse/COUCHDB-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798336#action_12798336
]
Brian Candler commented on COUCHDB-617:
---
The behaviour I'd like is for huge ints to remain as huge ints. Does anyone
object?
I imagine it should be OK to test from the browser, as long as you can examine
the raw text response before it has been JSON-parsed, but I am not an expert in
javascript-in-browser programming.
> 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
>
> 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] Commented: (COUCHDB-617) Large integers being turned into floats
[
https://issues.apache.org/jira/browse/COUCHDB-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798081#action_12798081
]
Brian Candler commented on COUCHDB-617:
---
> our forked version of mochijson2 did not have this guard that limits integers
> to 2^31
Yes, I just checked out r97 directly from google code to check:
$ erl +Bc
Erlang R13B01 (erts-5.7.2) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0]
[kernel-poll:false]
Eshell V5.7.2 (abort with ^G)
1> c(mochijson2).
{ok,mochijson2}
2> D = mochijson2:decode(<<"{\"v\":30}">>).
{struct,[{<<"v">>,30}]}
3> mochijson2:encode(D).
** exception error: undefined function mochinum:digits/1
in function mochijson2:'-json_encode_proplist/2-fun-0-'/3
in call from lists:foldl/3
in call from mochijson2:json_encode_proplist/2
4>
4> c(mochinum).
{ok,mochinum}
5> mochijson2:encode(D).
[123,[34,<<"v">>,34],58,"3.0e+9",125]
6>
> 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
>
> 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] Commented: (COUCHDB-617) Large integers being turned into floats
[
https://issues.apache.org/jira/browse/COUCHDB-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798075#action_12798075
]
Brian Candler commented on COUCHDB-617:
---
mochijson2.erl appears to be completely self-contained, so I just copied it
(the r97 version) across onto the newer machine and compiled it locally:
$ erl +Bc
Erlang R13B01 (erts-5.7.2) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0]
[kernel-poll:false]
Eshell V5.7.2 (abort with ^G)
1> c(mochijson2).
{ok,mochijson2}
2> D = mochijson2:decode(<<"{\"v\":30}">>).
{[{<<"v">>,30}]}
3> mochijson2:encode(D).
[123,[34,<<"v">>,34],58,"30",125]
4>
As you can see, it works fine.
> 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
>
> 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] Commented: (COUCHDB-617) Large integers being turned into floats
[
https://issues.apache.org/jira/browse/COUCHDB-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798073#action_12798073
]
Brian Candler commented on COUCHDB-617:
---
On the older machine (r97):
$ erl +Bc -pa /usr/local/lib/couchdb/erlang/lib/mochiweb-r97/ebin
Erlang (BEAM) emulator version 5.6.5 [source] [async-threads:0]
[kernel-poll:false]
Eshell V5.6.5 (abort with ^G)
1> D = mochijson2:decode(<<"{\"v\":30}">>).
{[{<<"v">>,30}]}
2> mochijson2:encode(D).
[123,[34,<<"v">>,34],58,"30",125]
On the newer machine (r113):
$ erl +Bc -pa /usr/local/lib/couchdb/erlang/lib/mochiweb-r113/ebin
Erlang R13B01 (erts-5.7.2) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0]
[kernel-poll:false]
Eshell V5.7.2 (abort with ^G)
1> D = mochijson2:decode(<<"{\"v\":30}">>).
{struct,[{<<"v">>,30}]}
2> mochijson2:encode(D).
[123,[34,<<"v">>,34],58,"3.0e+9",125]
Something has definitely changed, either with mochiweb or with the underlying
erlang platform.
Incidentally, the newer machine is Ubuntu 64-bi. Doesn't really explain why a
32-bit machine gets it right though :-)
> 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
>
> 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] Updated: (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
]
Brian Candler updated COUCHDB-617:
--
Summary: Large integers being turned into floats (was: View server turning
integers into floats)
> 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
>
> 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] Commented: (COUCHDB-617) View server turning integers into floats
[
https://issues.apache.org/jira/browse/COUCHDB-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798034#action_12798034
]
Brian Candler commented on COUCHDB-617:
---
Actually, the same is happening just when saving and retrieving documents (so
not touching the view server at all).
$ curl -X PUT -d '{"v":30}' http://127.0.0.1:5984/test_suite_db/xyzzy
{"ok":true,"id":"xyzzy","rev":"1-05551cfd0e8e3f5dc99054be3b105483"}
$ curl http://127.0.0.1:5984/test_suite_db/xyzzy
{"_id":"xyzzy","_rev":"1-05551cfd0e8e3f5dc99054be3b105483","v":3.0e+9}
> View server turning integers 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
>
> 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] Created: (COUCHDB-617) View server turning integers into floats
View server turning integers 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
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] Commented: (COUCHDB-356) batch=ok should take a wait=true option
[ https://issues.apache.org/jira/browse/COUCHDB-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793691#action_12793691 ] Brian Candler commented on COUCHDB-356: --- Err... you could have a very large number of small documents. Logs for example. > batch=ok should take a wait=true option > --- > > Key: COUCHDB-356 > URL: https://issues.apache.org/jira/browse/COUCHDB-356 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Reporter: Chris Anderson > Fix For: 0.11 > > > This would hold the connection to the client until the document has been > committed, instead of returning immediately with a 202 Accepted -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-604) _changes feed with ?feed=continuous does not return valid JSON
[
https://issues.apache.org/jira/browse/COUCHDB-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793203#action_12793203
]
Brian Candler commented on COUCHDB-604:
---
> if you want the heartbeat feature you'll still need a dummy record.
A simple newline would still be fine as a heartbeat for 'gets' readers of
course. What I meant was, if you are using a stream parser you probably won't
get an event for just reading a newline, so heartbeat would have to send some
real content to be useful in that case.
> _changes feed with ?feed=continuous does not return valid JSON
> --
>
> Key: COUCHDB-604
> URL: https://issues.apache.org/jira/browse/COUCHDB-604
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Affects Versions: 0.10
>Reporter: Joscha Feth
>Priority: Trivial
>
> When using the _changes interface via ?feed=continuous the JSON returned is
> rather
> a stream of JSON documents than a valid JSON file itself:
> {"seq":38,"id":"f473fe61a8a53778d91c38b23ed6e20f","changes":[{"rev":"9-d3e71c7f5f991b26fe014d884a27087f"}]}
> {"seq":68,"id":"2a574814d61d9ec8a0ebbf43fa03d75b","changes":[{"rev":"6-67179f215e42d63092dc6b2199a3bf51"}],"deleted":true}
> {"seq":70,"id":"75dbdacca8e475f5909e3cc298905ef8","changes":[{"rev":"1-0dee261a2bd4c7fb7f2abd811974d3f8"}]}
> {"seq":71,"id":"09fb03236f80ea0680a3909c2d788e43","changes":[{"rev":"1-a9646389608c13a5c26f4c14c6863753"}]}
> to be valid there needs to be a root element (and then an array with commata)
> like in the non-continuous feed:
> {"results":[
> {"seq":38,"id":"f473fe61a8a53778d91c38b23ed6e20f","changes":[{"rev":"9-d3e71c7f5f991b26fe014d884a27087f"}]},
> {"seq":68,"id":"2a574814d61d9ec8a0ebbf43fa03d75b","changes":[{"rev":"6-67179f215e42d63092dc6b2199a3bf51"}],"deleted":true},
> {"seq":70,"id":"75dbdacca8e475f5909e3cc298905ef8","changes":[{"rev":"1-0dee261a2bd4c7fb7f2abd811974d3f8"}]},
> {"seq":71,"id":"09fb03236f80ea0680a3909c2d788e43","changes":[{"rev":"1-a9646389608c13a5c26f4c14c6863753"}]},
> in short this means that if someone does not parse the change events in an
> object like manner (e.g. waiting for a line-ending and then parsing the
> line), but using a SAX-like parser (throwing events of each new object, etc.)
> and expecting the response to be JSON (which it is not, because its not
> {x:[{},{},{}]} but {}{}{} which is not valid) there is an error thrown.
> I can see, that people doing this line by line might be okay with the above
> approach, but the response is not valid JSON and it would be nice if there
> were a flag to make the response valid JSON.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-604) _changes feed with ?feed=continuous does not return valid JSON
[
https://issues.apache.org/jira/browse/COUCHDB-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793202#action_12793202
]
Brian Candler commented on COUCHDB-604:
---
> By the way, XMPP works the same - it basically has an infinitely long stream
> of XML elements
> flowing - but still starts with a root node and ends with a closing one to be
> valid XML.
Stream parsing is much more common in the XML world; unfortunately JSON stream
parsers are not (yet?) widespread.
> You might call it a feature request, but I think either the output should be
> valid JSON or not.
> If you tell me the output is not valid JSON, okay, but I couldn't read this
> from the docs, as all
> other _changes interfaces return valid JSON.
It's not valid JSON, and I would agree it's a bug if you're referring to the
Content-Type header which is returned:
$ curl -v -H "Accept: application/json"
http://127.0.0.1:5984/test_suite_db/_changes?feed=continuous
...
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Server: CouchDB/0.11.0a813819 (Erlang OTP/R12B)
< Date: Mon, 21 Dec 2009 13:35:52 GMT
< Content-Type: application/json
< Cache-Control: must-revalidate
<
I would also agree that it's inconsistent with the way a view is returned.
Views are complete JSON docs, but have newlines in magic places to make it
possible to parse them line-at-a-time.
$ curl -H "Accept: application/json"
http://127.0.0.1:5984/test_suite_db_a/_all_docs
{"total_rows":5,"offset":0,"rows":[
{"id":"6d85c1ca41bd9eb4435b2fcac3670b84","key":"6d85c1ca41bd9eb4435b2fcac3670b84","value":{"rev":"1-d4388236888cf366f3e888221968"}},
{"id":"927c96f86e2fdebbcae3520ac2054fbd","key":"927c96f86e2fdebbcae3520ac2054fbd","value":{"rev":"1-d4388236888cf366f3e888221968"}},
{"id":"bar","key":"bar","value":{"rev":"6-7c014f6deb5cd9935625a8f411f8db08"}},
{"id":"c134ca85221694a28f9ad8953b3087a7","key":"c134ca85221694a28f9ad8953b3087a7","value":{"rev":"1-d4388236888cf366f3e888221968"}},
{"id":"foo","key":"foo","value":{"rev":"21-b94c260d79b638231eb14b3de8458c2f"}}
]}
It would have been possible for feed=continuous to work this way too.
In that case I'd have thought the comma should appear at the *start* of each
line (apart from the first, obviously), otherwise you need a dummy record at
the end to close the stream cleanly. And if you want the heartbeat feature
you'll still need a dummy record.
> _changes feed with ?feed=continuous does not return valid JSON
> --
>
> Key: COUCHDB-604
> URL: https://issues.apache.org/jira/browse/COUCHDB-604
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Affects Versions: 0.10
>Reporter: Joscha Feth
>Priority: Trivial
>
> When using the _changes interface via ?feed=continuous the JSON returned is
> rather
> a stream of JSON documents than a valid JSON file itself:
> {"seq":38,"id":"f473fe61a8a53778d91c38b23ed6e20f","changes":[{"rev":"9-d3e71c7f5f991b26fe014d884a27087f"}]}
> {"seq":68,"id":"2a574814d61d9ec8a0ebbf43fa03d75b","changes":[{"rev":"6-67179f215e42d63092dc6b2199a3bf51"}],"deleted":true}
> {"seq":70,"id":"75dbdacca8e475f5909e3cc298905ef8","changes":[{"rev":"1-0dee261a2bd4c7fb7f2abd811974d3f8"}]}
> {"seq":71,"id":"09fb03236f80ea0680a3909c2d788e43","changes":[{"rev":"1-a9646389608c13a5c26f4c14c6863753"}]}
> to be valid there needs to be a root element (and then an array with commata)
> like in the non-continuous feed:
> {"results":[
> {"seq":38,"id":"f473fe61a8a53778d91c38b23ed6e20f","changes":[{"rev":"9-d3e71c7f5f991b26fe014d884a27087f"}]},
> {"seq":68,"id":"2a574814d61d9ec8a0ebbf43fa03d75b","changes":[{"rev":"6-67179f215e42d63092dc6b2199a3bf51"}],"deleted":true},
> {"seq":70,"id":"75dbdacca8e475f5909e3cc298905ef8","changes":[{"rev":"1-0dee261a2bd4c7fb7f2abd811974d3f8"}]},
> {"seq":71,"id":"09fb03236f80ea0680a3909c2d788e43","changes":[{"rev":"1-a9646389608c13a5c26f4c14c6863753"}]},
> in short this means that if someone does not parse the change events in an
> object like manner (e.g. waiting for a line-ending and then parsing the
> line), but using a SAX-like parser (throwing events of each new object, etc.)
> and expecting the response to be JSON (which it is not, because its not
> {x:[{},{},{}]} but {}{}{} which is not valid) there is an error thrown.
> I can see, that people doing this line by line might be okay with the above
> approach, but the response is not valid JSON and it would be nice if there
> were a flag to make the response valid JSON.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-573) Regex capture problem in emit functions
[
https://issues.apache.org/jira/browse/COUCHDB-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780929#action_12780929
]
Brian Candler commented on COUCHDB-573:
---
BTW I got an "Internal Server Error" from JIRA when adding that comment,
although the comment does seem to have attached itself successfully.
> Regex capture problem in emit functions
> ---
>
> Key: COUCHDB-573
> URL: https://issues.apache.org/jira/browse/COUCHDB-573
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.11
> Environment: Linux
>Reporter: Eric Desgranges
>Priority: Trivial
> Fix For: 0.11
>
>
> The capture variables $0, $1, $2... don't get instantiated in regex
> expressions placed in emit functions.
> Example:
> function(doc) { if (doc.EntityType != null) { emit(doc.ID.Value + '.' +
> doc.EntityType, { Type: doc.EntityType.replace(/[A-Z]/g, ' $0'),
> EntityType: TestTwo
> Returns:
> Type: " $0est $0wo"
> Instead of:
> Type: " Test Two"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-573) Regex capture problem in emit functions
[
https://issues.apache.org/jira/browse/COUCHDB-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780927#action_12780927
]
Brian Candler commented on COUCHDB-573:
---
There is no $0 in Javascript, but $& gives the whole substring which matches
the regexp. You can try it out using 'js' at the command line (under Ubuntu:
install the 'spidermonkey-bin' package)
js> 'TestTwo'.replace(/[A-Z]/g, ' $&')
Test Two
Incidentally, Ruby is the same. $0 is the name of the running script and is
nothing to do with regexp captures.
~$ irb --simple-prompt
>> $0
=> "irb"
>> "TestTwo".gsub!(/[A-Z]/) { " #{$&}" }
=> " Test Two"
>>
> Regex capture problem in emit functions
> ---
>
> Key: COUCHDB-573
> URL: https://issues.apache.org/jira/browse/COUCHDB-573
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.11
> Environment: Linux
>Reporter: Eric Desgranges
>Priority: Trivial
> Fix For: 0.11
>
>
> The capture variables $0, $1, $2... don't get instantiated in regex
> expressions placed in emit functions.
> Example:
> function(doc) { if (doc.EntityType != null) { emit(doc.ID.Value + '.' +
> doc.EntityType, { Type: doc.EntityType.replace(/[A-Z]/g, ' $0'),
> EntityType: TestTwo
> Returns:
> Type: " $0est $0wo"
> Instead of:
> Type: " Test Two"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-566) Invalid database name gives 500 response
Invalid database name gives 500 response
Key: COUCHDB-566
URL: https://issues.apache.org/jira/browse/COUCHDB-566
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Environment: 0.11.0b831082
Reporter: Brian Candler
Priority: Trivial
Attempting to create a database with an invalid name gives a 500 (server
failed) HTTP response. IMO this should be 400 (bad request). Perhaps worth
checking for other instances like this.
$ curl -X PUT http://127.0.0.1:5984/mirrorAgent1
{"error":"error","reason":"illegal_database_name"}
$ curl -v -X PUT http://127.0.0.1:5984/mirrorAgent1
* About to connect() to 127.0.0.1 port 5984 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 5984 (#0)
> PUT /mirrorAgent1 HTTP/1.1
> User-Agent: curl/7.18.0 (i486-pc-linux-gnu) libcurl/7.18.0 OpenSSL/0.9.8g zli
> Host: 127.0.0.1:5984
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Server: CouchDB/0.11.0b831082 (Erlang OTP/R12B)
< Date: Mon, 09 Nov 2009 19:51:28 GMT
< Content-Type: text/plain;charset=utf-8
< Content-Length: 51
< Cache-Control: must-revalidate
<
{"error":"error","reason":"illegal_database_name"}
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-562) link couchjs with bound libmozjs
[ https://issues.apache.org/jira/browse/COUCHDB-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774931#action_12774931 ] Brian Candler commented on COUCHDB-562: --- I belive that setting rpath is done using LD_RUN_PATH at compile time. The following works for me: $ ./bootstrap $ LD_RUN_PATH=/usr/lib/xulrunner-1.9.1.4 ./configure --with-js-lib=/usr/lib/xulrunner-1.9.1.4 --with-js-include=/usr/lib/xulrunner-devel-1.9.1.4/include $ LD_RUN_PATH=/usr/lib/xulrunner-1.9.1.4 make && sudo make install You can confirm that the binary has the library location coded into it: $ ldd /usr/local/lib/couchdb/bin/couchjs | grep moz libmozjs.so => /usr/lib/xulrunner-1.9.1.4/libmozjs.so (0x0031e000) So the solution might be just to include the above in the documentation. It would be nice if ./configure could carry the LD_RUN_PATH setting forward. And/or, it could append the --with-js-lib value onto any existing LD_RUN_PATH. > link couchjs with bound libmozjs > > > Key: COUCHDB-562 > URL: https://issues.apache.org/jira/browse/COUCHDB-562 > Project: CouchDB > Issue Type: Improvement > Components: Build System > Environment: linux, ubuntu,debian >Reporter: Meno Abels > Fix For: 0.10 > > > If you build the couchdb from the source with a prefix set and > --with-js-[lib|include] option the resulting couchjs programm in > /lib/couchdb/bin/couchjs does not know where to find the specified > libmozjs.so which was specified in with-js-lib. This causes that quite all > test will fail. > To fix this the rpath has to setup during the compile. I don't had a look > where to do this. > but a small shell wrapper fix it also > #!/bin/sh > LD_LIBRARY_PATH=... exec $0.orig $@ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-549) include_docs=true doesn't honour conflicts=true
include_docs=true doesn't honour conflicts=true --- Key: COUCHDB-549 URL: https://issues.apache.org/jira/browse/COUCHDB-549 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.11 Reporter: Brian Candler Priority: Minor When you read a view and use the option 'include_docs=true' to get the source document in each result row, the option 'conflicts=true' is not honoured. You do not see a _conflicts member in the document, even if it is in a conflicting state. This feature request could be expanded in a couple of directions: 1. Make include_docs=true honour *all* options which a straightforward GET would honour - e.g. revs, revs_info, open_revs. Maybe this would be straightforward if they shared the same code path and options processing. 2. It has been suggested that 'conflicts=true' could be the default anyway. That is, whenever you retrieve a document, you get a _conflicts member if it is in a conflicting state, without having to ask for it. This would be unlikely to break things, but would make it less likely that conflicts would go unnoticed, and it would simplify the API a little. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-548) Limitations of open_revs=all
Limitations of open_revs=all
Key: COUCHDB-548
URL: https://issues.apache.org/jira/browse/COUCHDB-548
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Reporter: Brian Candler
Priority: Minor
The GET option ?open_revs=all would be useful for retrieving all conflicting
versions of a document in one go, but has the following problems.
1. The documents are returned in an arbitrary order which is unrelated to the
conflict-winning algorithm. For example, you can't rely on the first revision
returned being the one which a plain GET would return.
2. It includes tips of branches which are no longer live (i.e. the tip document
has been deleted). Although these can be filtered out client-side by looking
for a "_deleted":true member, it transfers unnecessary revs, potentially a
large number of them.
3. It is somewhat inconvenient that it returns an array of {"ok":{..doc..}} or
"missing":"rev", rather than just an array of docs. Again, this can be
normalized client-side. But I observe that if only live branches were returned,
then they would always be "ok" and so this layer wouldn't be needed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-499) allow /etc/default/couchdb to control whether couchdb is started by default
[ https://issues.apache.org/jira/browse/COUCHDB-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754492#action_12754492 ] Brian Candler commented on COUCHDB-499: --- On my Ubuntu Hardy desktop: $ ls /etc/default/ acpid ddclient pcmcia acpi-supportdevpts pmi alsaexim4portmap apache2 fetchmailpound apache2.dpkg-oldhal powernowd apmdhalt pulseaudio apport iodine rcS avahi-daemonklogdrsync bittorrent linux-restricted-modules-common slapd bluetooth lvm-common smartmontools bluetooth.dpkg-new mdadmssh bootlogdnfs-common syslogd brltty nfs-kernel-servertmpfs console-setup ntp ufw cupsys ntpdate useradd dbusnvidia-kernel In most cases these files aren't used for deciding whether the server is stopped or started. e.g. $ cat /etc/default/ntp NTPD_OPTS='-g' $ If you want that package installed but not running, you'd use update-rc.d However perhaps a better example is exim4, which has a number of options including no daemon, or a daemon which is just a queue runner, or a daemon which is both queue runner or smtp listener. This is configured in /etc/default/exim4 and so the user can select it using dpkg-reconfigure # /etc/default/exim4 EX4DEF_VERSION='' # 'combined' - one daemon running queue and listening on SMTP port # 'no' - no daemon running the queue # 'separate' - two separate daemons # 'ppp' - only run queue with /etc/ppp/ip-up.d/exim4. # 'nodaemon' - no daemon is started at all. # 'queueonly' - only a queue running daemon is started, no SMTP listener. # setting this to 'no' will also disable queueruns from # /etc/ppp/ip-up.d/exim4 QUEUERUNNER='combined' # how often should we run the queue QUEUEINTERVAL='30m' # options common to quez-runner and listening daemon COMMONOPTIONS='' # more options for the daemon/process running the queue (applies to the one # started in /etc/ppp/ip-up.d/exim4, too. QUEUERUNNEROPTIONS='' # special flags given to exim directly after the -q. See exim(8) QFLAGS='' # options for daemon listening on port 25 SMTPLISTENEROPTIONS='' Regards, Brian. > allow /etc/default/couchdb to control whether couchdb is started by default > --- > > Key: COUCHDB-499 > URL: https://issues.apache.org/jira/browse/COUCHDB-499 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 0.10 > Environment: Ubuntu 9.10 (Karmic) >Reporter: Elliot Murphy >Priority: Minor > Fix For: 0.10 > > Attachments: control-service-start.patch > > > couchdb starts by default when installed on Ubuntu (or any debian derivative). > In Ubuntu, we are including couchdb in the default desktop install. > however, we are not using the system couchdb, we are starting a per-user > couchdb instance on-demand. > separately, ubuntu is working on minimizing boot times. > it would be nice if laptops and netbooks did not have couchdb startup time > included in a normal system boot unless the user really wanted to have the > system couchdb starting up. this is the Ubuntu bug number for reference: > https://code.edge.launchpad.net/bugs/427036 > One way to fix this would be to use a variable in /etc/default/couchdb to > determine whether or not to start the system couchdb instance. This is the > approach that is taken by pulseaudio, fetchmail, and monit. I'm discussing > this fix with Ubuntu core-devs now: > https://code.edge.launchpad.net/~statik/ubuntu/karmic/couchdb/fix-bug427036/+merge/11543 > I'm also attaching a patch which changes the init script and > /etc/couchdb/default in the way I've just described. -- 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] 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] Commented: (COUCHDB-465) Produce sequential, but unique, document id's
[ https://issues.apache.org/jira/browse/COUCHDB-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742970#action_12742970 ] Brian Candler commented on COUCHDB-465: --- I'd like to suggest an alternative algorithm for consideration. - first 48 bits of the UUID is the time, in milliseconds, since 1 Jan 1970 - remaining 80 bits starts as a random value and increments from there, for example when doing a _bulk_docs insert (*) I have been using this algorithm for a while, generated client-side - it's in my 'couchtiny' ruby client. I did it this way so as to get monotonically-increasing doc ids; a view with equal keys will sort them in order of insertion into the DB. It also avoids having to keep a separate "created_at" timestamp field, because you can just get it from the id. def created_at Time.at(id[0,12].to_i(16) / 1000.0) rescue nil end Of course, the fact I generate uids like this demonstrates that there's no one-size-fits-all solution, but I just thought it was worth mentioning because you should get the B-tree insertion boost as a side-effect too. Regards, Brian. (*) It's your choice whether you want to re-randomize this when the next millisecond comes along, or just leave it to increment as a serial number. Even if you have multiple servers inserting documents into the same database, the chances of them using the same serial number within the same millisecond are infinitessimal, as long as they all start from an independent random point within the 2^80 possibilities. Wrapping would be very rare, but what I currently do is re-randomize for each bulk insert, and choose a starting random value which is more than 2^32 away from the ceiling. > 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 > > > 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-449) Turn off delayed commits by default
[
https://issues.apache.org/jira/browse/COUCHDB-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739942#action_12739942
]
Brian Candler commented on COUCHDB-449:
---
Just to be clear: _changes is supposed only to update after a commit has
taken place, not after a write?
If so, I cannot demonstrate it. If I write a document and then immediately
read _changes, it always appears. See below at (*).
Furthermore, the same is true if I run
$ curl http://127.0.0.1:5984/test/_changes?feed=continuous
in another window. As soon as I add a document in the first window, it
appears in the _changes feed.
My very rough scan of the source suggests that a delayed commit should take
place after 1 second:
Delay and (Db#db.waiting_delayed_commit == nil) ->
Db#db{waiting_delayed_commit=
erlang:send_after(1000, self(), delayed_commit)};
So if that's right, and what you say is true, then I would expect not to see
the document in _changes for this long.
OTOH, with batch=ok the commit is delayed indefinitely. I have raised this
as a separate ticket COUCHDB-454)
All tested with HEAD (git commit aebdb31001126dab6b579b8cc2e605ef7ec499c6)
and 12b5 under Jaunty.
Regards,
Brian.
(*)
$ curl -X DELETE http://127.0.0.1:5984/test
{"ok":true}
$ curl -X PUT http://127.0.0.1:5984/test
{"ok":true}
$ curl http://127.0.0.1:5984/test/_changes
{"results":[
],
"last_seq":0}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test; curl
http://127.0.0.1:5984/test/_changes
{"ok":true,"id":"70708dcbc2977b759365f9731f27","rev":"1-967a00dff5e02add41819138abb3284d"}
{"results":[
{"seq":1,"id":"70708dcbc2977b759365f9731f27","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":1}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test; curl
http://127.0.0.1:5984/test/_changes
{"ok":true,"id":"1d4596c1cb715c0da9f99980fea0a3a2","rev":"1-967a00dff5e02add41819138abb3284d"}
{"results":[
{"seq":1,"id":"70708dcbc2977b759365f9731f27","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":2,"id":"1d4596c1cb715c0da9f99980fea0a3a2","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":2}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test; curl
http://127.0.0.1:5984/test/_changes
{"ok":true,"id":"a2feeaaca391446bb7a0f24c359ff79e","rev":"1-967a00dff5e02add41819138abb3284d"}
{"results":[
{"seq":1,"id":"70708dcbc2977b759365f9731f27","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":2,"id":"1d4596c1cb715c0da9f99980fea0a3a2","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":3,"id":"a2feeaaca391446bb7a0f24c359ff79e","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":3}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test; curl -X POST -d'{}'
http://127.0.0.1:5984/test; curl -X POST -d'{}' http://127.0.0.1:5984/test;
curl http://127.0.0.1:5984/test/_changes
{"ok":true,"id":"a2262a5904690aec5c64bb61f44903ed","rev":"1-967a00dff5e02add41819138abb3284d"}
{"ok":true,"id":"26fdac7e139531e0f4352a089d4db7f4","rev":"1-967a00dff5e02add41819138abb3284d"}
{"ok":true,"id":"f6bb36540484788becd54391dbc6189b","rev":"1-967a00dff5e02add41819138abb3284d"}
{"results":[
{"seq":1,"id":"70708dcbc2977b759365f9731f27","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":2,"id":"1d4596c1cb715c0da9f99980fea0a3a2","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":3,"id":"a2feeaaca391446bb7a0f24c359ff79e","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":4,"id":"a2262a5904690aec5c64bb61f44903ed","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":5,"id":"26fdac7e139531e0f4352a089d4db7f4","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":6,"id":"f6bb36540484788becd54391dbc6189b","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":6}
> Turn off delayed commits by default
> ---
>
> Key: COUCHDB-449
> URL: https://issues.apache.org/jira/browse/COUCHDB-449
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.9, 0.9.1
>Reporter: Jan Lehnardt
>Priority: Blocker
> Fix For: 0.10
>
>
> Delayed commits make CouchDB significantly faster. They also open a one
> second window for data loss. In 0.9 and trunk, delayed commits are enabled by
> default and can be overridden with HTTP headers and an explicit API call to
> flush the write buffer. I suggest to turn off delayed commits by default and
> use the same overrides to enable it per request. A per-database option is
> possible, too.
> One concern is developer workflow speed. The setting affects the test suite
> performance significantly. I'd opt to change couch.js to set the appropriate
> header to enable delayed commits for tests.
> CouchDB should guarantee data s
[jira] Created: (COUCHDB-454) batch=ok buffers indefinitely
batch=ok buffers indefinitely
-
Key: COUCHDB-454
URL: https://issues.apache.org/jira/browse/COUCHDB-454
Project: CouchDB
Issue Type: Bug
Components: Database Core
Environment: CouchDB HEAD (commit commit
aebdb31001126dab6b579b8cc2e605ef7ec499c6)
Ubuntu Jaunty, Erlang 12B5
Reporter: Brian Candler
It appears that documents written with batch=ok are buffered indefinitely. They
don't appear in the _changes feed, nor in _all_docs, until you POST to
_ensure_full_commit. This is despite me running with standard default.ini which
has batch_save_interval=1000 (milliseconds)
$ curl -X DELETE http://127.0.0.1:5984/test
{"ok":true}
$ curl -X PUT http://127.0.0.1:5984/test
{"ok":true}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test
{"ok":true,"id":"1b1337e31c4d9b41119d51db78ffebe3","rev":"1-967a00dff5e02add41819138abb3284d"}
$ curl http://127.0.0.1:5984/test/_all_docs
{"total_rows":1,"offset":0,"rows":[
{"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
]}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
{"ok":true,"id":"ba37caf17a24236d243e9ab2c4c6daff"}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
{"ok":true,"id":"e5d8bb7c74ca3cca4aabea8107620fad"}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
{"ok":true,"id":"9bb2fb958f9112d79b4f388514c0ba7c"}
$ curl http://127.0.0.1:5984/test/_all_docs
{"total_rows":1,"offset":0,"rows":[
{"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
]}
$ sleep 60
$ curl http://127.0.0.1:5984/test/_all_docs
{"total_rows":1,"offset":0,"rows":[
{"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
]}
$ curl -X POST http://127.0.0.1:5984/test/_ensure_full_commit
{"ok":true,"instance_start_time":"1249546668867264"}
$ curl http://127.0.0.1:5984/test/_all_docs
{"total_rows":4,"offset":0,"rows":[
{"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
{"id":"9bb2fb958f9112d79b4f388514c0ba7c","key":"9bb2fb958f9112d79b4f388514c0ba7c","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
{"id":"ba37caf17a24236d243e9ab2c4c6daff","key":"ba37caf17a24236d243e9ab2c4c6daff","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
{"id":"e5d8bb7c74ca3cca4aabea8107620fad","key":"e5d8bb7c74ca3cca4aabea8107620fad","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
]}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-449) Turn off delayed commits by default
[ https://issues.apache.org/jira/browse/COUCHDB-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739430#action_12739430 ] Brian Candler commented on COUCHDB-449: --- Or perhaps you could set a different periodic flush interval for each database, with 0 equivalent to no delayed commit. For me, the question is specifically, what guarantees does CouchDB give to clients about your data safety, and when - for example, at the point where you get a HTTP response? There are at least three different scenarios that I'm aware of at the moment. 1. client supplies 'batch=ok' URL parameter 2. client supplies no special parameters 3. client supplies 'X-Couch-Full-Commit: true' header >From the client's perspective, I can see no difference between (1) and (2). After receiving a HTTP response, the data is likely to make it to disk at some time in the future, but it could be lost if the plug is pulled in the next few seconds. In case (3), the document is guaranteed to be on disk after the HTTP response is returned [as long as drive internal write cache is disabled]. This is equivalent to "QOS level 1" in the MQTT protocol: http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac10850_.htm However, it also forces writes of everything received up to this point, so it's very inefficient if you are doing lots of writes with this header on. Sometimes, you don't require data to be written to disk immediately, but you do want to be notified *when* it has been written to disk in order to take some subsequent action (such as acknowledging the successful save to a downstream consumer). I would like to propose an alternative approach similar to TCP sequence numbers. We already have a sequence number which counts documents added to the database (update_seq). I suggest we keep a separate watermark which is the sequence number when the database was last flushed to disk (say flush_seq). Now: - when you PUT a document, send the update_seq as part of the response (let's call it doc_seq) - update_seq may continue to increment as more documents are updated - at some point in the future, when data is flushed to disk, set flush_seq := update_seq - if the client is interested to know when its document has been flushed to disk, it can poll mydb to check for flush_seq >= doc_seq - it could be an option in the HTTP request to delay the response until flush_seq >= doc_seq That means you would get the benefit of knowing that the document had been committed to disk, without the cost of having to commit it. Rather, you wait until someone else wants to force a full commit, or the periodic full commit takes place. Then the only per-database tunable you need is the periodic commit interval. Set it to 5 seconds for logging databases; 0.2 for RADIUS accounting (where you want to generate a response within 200ms); and 0 if you want every single document to be committed as soon as it arrives. Thoughts? Something like this is doable at present, but requires a buffering proxy. For example, you can receive RADIUS accounting updates into a buffer, then every 200ms do a POST to _bulk_docs with X-Couch-Full-Commit: true and return success to all the clients. Since CouchDB has to buffer these documents in the VFS cache anyway, it would be convenient (and more efficient) to let it handle the periodic flushing too. Regards, Brian. > Turn off delayed commits by default > --- > > Key: COUCHDB-449 > URL: https://issues.apache.org/jira/browse/COUCHDB-449 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Affects Versions: 0.9, 0.9.1 >Reporter: Jan Lehnardt >Priority: Blocker > Fix For: 0.10 > > > Delayed commits make CouchDB significantly faster. They also open a one > second window for data loss. In 0.9 and trunk, delayed commits are enabled by > default and can be overridden with HTTP headers and an explicit API call to > flush the write buffer. I suggest to turn off delayed commits by default and > use the same overrides to enable it per request. A per-database option is > possible, too. > One concern is developer workflow speed. The setting affects the test suite > performance significantly. I'd opt to change couch.js to set the appropriate > header to enable delayed commits for tests. > CouchDB should guarantee data safety first and speed second, with sensible > overrides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-404) restfull and shorter urls for lists and shows
[ https://issues.apache.org/jira/browse/COUCHDB-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12728135#action_12728135 ] Brian Candler commented on COUCHDB-404: --- > Views are available ... also on /db/_view/designame/viewname ... > Lists are available ... also on /db/_view/designame/viewname?list=listname Won't that break attachments to design documents? Those are pretty fundamental to couchapps. Also: my recollection is that the URLs were changed quite recently to the current format to make them *more* RESTful - specifically, that lists and shows could link to each other using relative URLs, without having to have hard-coded knowledge of the design document they were sitting in. > restfull and shorter urls for lists and shows > - > > Key: COUCHDB-404 > URL: https://issues.apache.org/jira/browse/COUCHDB-404 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 0.10 > Environment: * >Reporter: Benoit Chesneau > > We discussing yesterday with @jchris and @jasondavies about shortening > shows and lists urls and we arrived on this format : > /db/docid?show=dname/showname > /db/_view/dname/vname?list=listname > This change is very usefull since it allows shorter urls and I think > it's more RESTFul. I had time this morning to write this and I created > a branch on my github repository : > http://github.com/benoitc/couchdb/tree/formuri > To do this I refactored a little couch_httpd_show to reuse code to > display lists and shows and added URL parameters parsing/validation. > All changes made in this branch don't break current CouchDB behavior > so : > * Views are available on > /db/_design/designame/_view/viewname (current behavior) but also on > /db/_view/designame/viewname > * Lists are available on > /db/_design/designame/_list/listname/viewname (current behavior) > but also on > /db/_view/designame/viewname?list=listname > * Shows are available on > /db/_design/designame/_show/showname/docid > but also on > /db/docid?show=designame/showname -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-403) User-defined GroupRowsFun
User-defined GroupRowsFun - Key: COUCHDB-403 URL: https://issues.apache.org/jira/browse/COUCHDB-403 Project: CouchDB Issue Type: Wish Components: Database Core, HTTP Interface Reporter: Brian Candler Priority: Minor CouchDB has hard-coded functionality for grouping. From the user's point of view: group_level=N will truncate Array keys to the first N elements, and that's it. (*) It would be wonderful if application-specific grouping functions could be added. Useful examples include: * for string keys, truncate to the first N characters (e.g. group by first 3 letters of surname) * for numeric keys, trunc(k/N) (e.g. divide by 100 would give you buckets of 0..99, 100..199, 200..299 etc) * combine with group_level: e.g. truncate array to first two elements plus the third element divided by 100 ["string1","string2",Number,"rest"] => ["string1","string2",trunc(Number/100)] * for numeric keys: use trunc(log(V) * N) for exponential buckets * for hexadecimal-string keys: right-shift N places * ...etc In each case N would be a parameter chosen at query time, like group_level is now. It would be sufficient just to have a hook to statically link Erlang functions to do this. There would then need to be two new HTTP parameters: one to choose the grouping function and one for any arguments it needs. Theoretically this function could also be handed off to the external view server so the logic could be written in Javascript or whatever, but I think it would be too slow in practice. Note: group truncation functions would have need to meet certain constraints to work with grouping logic. Something like: K1 <= K2 implies grouptrunc(K1) <= grouptrunc(K2) (*) It's not implemented exactly like that. As far as I can see, there's one function to compare keys for equality by looking at the first N elements (GroupRowsFun), and another function truncates them when emitting them (RespFun). For adding bolt-on functions it would be more convenient just to define a single group key truncation function. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-399) [PATCH] speed up toJSON()
[
https://issues.apache.org/jira/browse/COUCHDB-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Candler updated COUCHDB-399:
--
Attachment: main.js.patch
> [PATCH] speed up toJSON()
> -
>
> Key: COUCHDB-399
> URL: https://issues.apache.org/jira/browse/COUCHDB-399
> Project: CouchDB
> Issue Type: Improvement
> Components: JavaScript View Server
> Environment: {"couchdb":"Welcome","version":"0.10.0a787397"}
>Reporter: Brian Candler
>Priority: Minor
> Attachments: main.js.patch
>
>
> This patch is a trivial optimisation of the toJSON() function in main.js
> It provides a surprising speedup. For example, in my real-world app, it
> reduces indexing time of ~3,800 docs from 80 seconds to 60 seconds. And using
> the benchmark script I posted to dev@, I see:
> 2.877 -> 2.062 secs (3000 docs, emit one k/v per doc)
> 13.522 -> 7.585 secs (3000 docs, emit 10 simple k/v per doc)
> 19.049 -> 12.714 secs (3000 docs, emit 10 compound k/v per doc)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-399) [PATCH] speed up toJSON()
[PATCH] speed up toJSON()
-
Key: COUCHDB-399
URL: https://issues.apache.org/jira/browse/COUCHDB-399
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Environment: {"couchdb":"Welcome","version":"0.10.0a787397"}
Reporter: Brian Candler
Priority: Minor
This patch is a trivial optimisation of the toJSON() function in main.js
It provides a surprising speedup. For example, in my real-world app, it reduces
indexing time of ~3,800 docs from 80 seconds to 60 seconds. And using the
benchmark script I posted to dev@, I see:
2.877 -> 2.062 secs (3000 docs, emit one k/v per doc)
13.522 -> 7.585 secs (3000 docs, emit 10 simple k/v per doc)
19.049 -> 12.714 secs (3000 docs, emit 10 compound k/v per doc)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-383) HTTP get parameter strictness/looseness
[
https://issues.apache.org/jira/browse/COUCHDB-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722420#action_12722420
]
Brian Candler commented on COUCHDB-383:
---
I'd say there are dragons in accepting random unknown query strings too. A few
times I have done something like
?include_attachments=true
instead of
?attachments=true
(or is it the other way round?) Having erroneous parameters fail silently is
not, IMO, very helpful. However I agree that the situation wasn't very
consistent as it was.
Having "map=true" doesn't seem sensible to me, given that it's just the
negative of "reduce=false".
Having views default to reduce=false would suit me well (i.e. if you want it
reduced, you have to ask for reduce=true), but would be hugely non backwards
compatible. Ditto for your suggestion of _map and _red.
Perhaps we could even have multiple reduce functions behind the same map - so
you'd have to select which one you wanted anyway.
> HTTP get parameter strictness/looseness
> ---
>
> Key: COUCHDB-383
> URL: https://issues.apache.org/jira/browse/COUCHDB-383
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.0
> Environment: Linux Debian 5.0 (VMware image)
>Reporter: Simon Thulbourn
>Assignee: Paul Joseph Davis
>Priority: Minor
> Fix For: 0.10
>
>
> The use of GET params in a URL is either too loose or too strict depending on
> your point of view.
> Adding extra GET params that are not needed to a query works on every request
> except for /dbname/_all_docs, in this event CouchDB returns an error.
> Test Case:
> /foobar/_all_docs?callback=jsonp1244562168058&_=1244562168079
> Returns: jsonp1244562168058({"error":"query_parse_error","reason":"Invalid
> URL parameter: \"_\""});
> NOTE: this is not just a JSONP error, this is just how I found it.
> Ideally, CouchDB either needs to accept this or to error on every request
> with that contains erroneous GET parameters.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-383) HTTP get parameter strictness/looseness
[
https://issues.apache.org/jira/browse/COUCHDB-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722350#action_12722350
]
Brian Candler commented on COUCHDB-383:
---
If you're gonna fully relax, then I think you might also want to accept things
like reduce=false on a map-only view. (Perhaps even ignore reduce=true too?)
Right now, nonsense like 'reducz=false' is accepted, but the reasonable
'reduce=false' is not:
$ curl http://127.0.0.1:5984/
{"couchdb":"Welcome","version":"0.10.0a787002"}
$ curl 'http://127.0.0.1:5984/test/_design/test/_view/test?reduce=false'
{"error":"query_parse_error","reason":"Invalid URL parameter `reduce` for map
view."}
This is a pain, given that map-reduce views default to reduce=true. That is, if
you know you only want the map part of the view, but you don't know if it has a
reduce part or not, you may end up having to submit the query twice.
> HTTP get parameter strictness/looseness
> ---
>
> Key: COUCHDB-383
> URL: https://issues.apache.org/jira/browse/COUCHDB-383
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.0
> Environment: Linux Debian 5.0 (VMware image)
>Reporter: Simon Thulbourn
>Assignee: Paul Joseph Davis
>Priority: Minor
> Fix For: 0.10
>
>
> The use of GET params in a URL is either too loose or too strict depending on
> your point of view.
> Adding extra GET params that are not needed to a query works on every request
> except for /dbname/_all_docs, in this event CouchDB returns an error.
> Test Case:
> /foobar/_all_docs?callback=jsonp1244562168058&_=1244562168079
> Returns: jsonp1244562168058({"error":"query_parse_error","reason":"Invalid
> URL parameter: \"_\""});
> NOTE: this is not just a JSONP error, this is just how I found it.
> Ideally, CouchDB either needs to accept this or to error on every request
> with that contains erroneous GET parameters.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-362) Malformed _attachments gives 500 and function_clause error
Malformed _attachments gives 500 and function_clause error
--
Key: COUCHDB-362
URL: https://issues.apache.org/jira/browse/COUCHDB-362
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Environment: {"couchdb":"Welcome","version":"0.10.0a778641"}
Reporter: Brian Candler
Priority: Minor
Creating a document with bad format of the _attachments structure gives a 500
error and Erlang function_clause exceptions.
example 1
require 'rubygems'
require 'restclient'
require 'json'
DB="http://127.0.0.1:5984/test";
RestClient.delete DB rescue nil
RestClient.put DB, {}.to_json
doc = {"_id"=>"test","hello"=>"world","_attachments"=>{
"foo"=>["This is a test"].pack("m"),
}}
puts RestClient.post("#{DB}/_bulk_docs",
{'docs'=>[doc],'all_or_nothing'=>true}.to_json)
This aborts with 500 and logs:
[Tue, 26 May 2009 10:14:53 GMT] [error] [<0.98.0>] Uncaught error in HTTP
request: {error,function_clause}
[Tue, 26 May 2009 10:14:53 GMT] [info] [<0.98.0>] Stacktrace:
[{couch_doc,'-transfer_fields/2-fun-0-',
[{<<"foo">>,<<"VGhpcyBpcyBhIHRlc3Q=\n">>}]},
{lists,flatmap,2},
{couch_doc,transfer_fields,2},
{couch_httpd_db,'-db_req/2-fun-0-',1},
{lists,map,2},
{couch_httpd_db,db_req,2},
{couch_httpd_db,do_db_req,2},
{couch_httpd,handle_request,5}]
[Tue, 26 May 2009 10:14:53 GMT] [info] [<0.98.0>] 127.0.0.1 - - 'POST'
/test/_bulk_docs 500
example 2
require 'rubygems'
require 'restclient'
require 'json'
DB="http://127.0.0.1:5984/test";
RestClient.delete DB rescue nil
RestClient.put DB, {}.to_json
doc = {"_id"=>"test","hello"=>"world","_attachments"=>{
"foo"=>{"content_type"=>"text/plain","data"=>["This is a test"].pack("m")},
}}
puts RestClient.post("#{DB}/_bulk_docs",
{'docs'=>[doc],'all_or_nothing'=>true}.to_json)
This also aborts with 500 and logs:
[Tue, 26 May 2009 10:16:10 GMT] [error] [<0.199.0>] Uncaught error in HTTP
request: {error,function_clause}
[Tue, 26 May 2009 10:16:10 GMT] [info] [<0.199.0>] Stacktrace:
[{couch_util,decode1,
[<<"\n">>,
<<84,104,105,115,32,105,115,32,97,32,116,101,115,
116,1>>]},
{couch_doc,'-transfer_fields/2-fun-0-',1},
{lists,flatmap,2},
{couch_doc,transfer_fields,2},
{couch_httpd_db,'-db_req/2-fun-0-',1},
{lists,map,2},
{couch_httpd_db,db_req,2},
{couch_httpd_db,do_db_req,2}]
[Tue, 26 May 2009 10:16:10 GMT] [info] [<0.199.0>] 127.0.0.1 - - 'POST'
/test/_bulk_docs 500
In this case, it seems only that the trailing newline in the base64
representation is causing the error (adding a 'chomp' makes the program work).
But it's not exactly a helpful error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-354) Ungraceful behaviour if view returns a function
[
https://issues.apache.org/jira/browse/COUCHDB-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712141#action_12712141
]
Brian Candler commented on COUCHDB-354:
---
It's the only version provided in both Ubuntu Hardy and Ubuntu Jaunty. It also
works perfectly fine for me in general, and I don't think the problem is
anything to do with the Javascript engine.
Hidden in the barf you can see what the error is - it's caused by the toJSON
function in main.js, which in skeleton form looks like this: it's a strange
sort of case statement.
return {'Array':f1, 'Boolean':f2, ...}[val.constructor.name](val);
The problem is that if val is a function, val.constructor.name is 'Function'
which is not defined in the object, so you are essentially calling
undefined(val).
You can get a rather better error by catching unexpected values, e.g. like this:
--- main.js.orig2009-05-22 16:26:22.0 +0100
+++ main.js 2009-05-22 16:32:05.0 +0100
@@ -306,7 +306,7 @@
if (typeof(val) == "xml") { // E4X support
val = val.toXMLString();
}
- return {
+ var handlers = {
"Array": function(v) {
var buf = [];
for (var i = 0; i < v.length; i++) {
@@ -351,7 +351,11 @@
}
return '"' + v + '"';
}
- }[val != null ? val.constructor.name : "Object"](val);
+ }
+ var k = val != null ? val.constructor.name : "Object";
+ var h = handlers[k];
+ if (!h) { throw ("Cannot encode '" + k + "' value as JSON") };
+ return h(val);
}
function compileFunction(source) {
But I still get a 'badmatch' crash:
** Reason for termination ==
** {{badmatch,<<"Cannot encode 'Function' value as JSON">>},
[{couch_query_servers,'-rereduce/3-fun-0-',3},
{lists,zipwith,3},
{couch_query_servers,rereduce,3},
{couch_view_group,'-init_group/4-fun-0-',4},
{couch_btree,'-write_node/3-lc$^0/1-0-',3},
{couch_btree,write_node,3},
{couch_btree,complete_root,2},
{couch_btree,query_modify,4}]}
Given that you've closed this ticket a second time, I'll defer to your
judgement that you do not think this should be fixed, and leave it closed.
> Ungraceful behaviour if view returns a function
> ---
>
> Key: COUCHDB-354
> URL: https://issues.apache.org/jira/browse/COUCHDB-354
> Project: CouchDB
> Issue Type: Improvement
> Components: JavaScript View Server
> Environment: {"couchdb":"Welcome","version":"0.10.0a776990"}
>Reporter: Brian Candler
>Priority: Minor
> Attachments: barf.log, test_reduce_barf.rb
>
>
> If a typo in a view definition causes it to return a function instead of a
> normal value:
> * the view server crashes
> * you get a huge Erlang barf in the log with worrying messages like "OS
> process timed out" and "brutal kill"
> I got all this just by accidentally writing "vs.shift" instead of "vs.shift()"
> The fundamental problem is that a function cannot be serialised in toJSON,
> but the error message is not helpful:
> OS Process Log Message: Error converting object to JSON: TypeError:
> {Array:function (v) {var ... snip loads ... "Object"] is not a function
> When actually the problem is that the object I was trying to convert *was* a
> function :-)
> I will attach some code which replicates this, and the barf generated.
> Of course this is entirely down to user error in an invalid map/reduce
> function. However there's already a clean error for 'undefined', maybe this
> could be done for 'function' too (or indeed any non-serialisable entity)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-354) Ungraceful behaviour if view returns a function
[
https://issues.apache.org/jira/browse/COUCHDB-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712095#action_12712095
]
Brian Candler commented on COUCHDB-354:
---
This is really odd: trunk still barfs for me. And what's especially odd is (a)
your debug log doesn't show *anything* wrong with that Javascript at all, and
(b) your reduce output is completely empty, not even 'key'=>null. Does all_docs
show the documents? You're not running the eep-0018 branch?
I get exactly the same:
$ curl http://127.0.0.1:5984/
{"couchdb":"Welcome","version":"0.10.0a777521"}
$ ruby ~/test_reduce_barf.rb
reduce across all says:
/var/lib/gems/1.8/gems/rest-client-0.9.2/lib/restclient/request.rb:144:in
`process_result': HTTP status code 500 (RestClient::RequestFailed)
from
/var/lib/gems/1.8/gems/rest-client-0.9.2/lib/restclient/request.rb:106:in
`transmit'
from /usr/lib/ruby/1.8/net/http.rb:543:in `start'
from
/var/lib/gems/1.8/gems/rest-client-0.9.2/lib/restclient/request.rb:103:in
`transmit'
from
/var/lib/gems/1.8/gems/rest-client-0.9.2/lib/restclient/request.rb:36:in
`execute_inner'
from
/var/lib/gems/1.8/gems/rest-client-0.9.2/lib/restclient/request.rb:28:in
`execute'
from
/var/lib/gems/1.8/gems/rest-client-0.9.2/lib/restclient/request.rb:12:in
`execute'
from /var/lib/gems/1.8/gems/rest-client-0.9.2/lib/restclient.rb:57:in
`get'
from /home/brian/test_reduce_barf.rb:56
$ curl http://127.0.0.1:5984/_log
{trap_exit,true},
{status,running},
{heap_size,987},
{stack_size,23},
{reductions,751}],
[]]}}
[Fri, 22 May 2009 13:53:41 GMT] [error] [<0.44.0>] {error_report,<0.22.0>,
{<0.44.0>,supervisor_report,
[{supervisor,{local,couch_secondary_services}},
{errorContext,child_terminated},
{reason,{os_process_error,"OS process timed out."}},
{offender,[{pid,<0.45.0>},
{name,view_manager},
{mfa,{couch_view,start_link,[]}},
{restart_type,permanent},
{shutdown,brutal_kill},
{child_type,worker}]}]}}
[Fri, 22 May 2009 13:53:41 GMT] [info] [<0.78.0>] 127.0.0.1 - - 'GET'
/test/_design/test/_view/test 500
[Fri, 22 May 2009 13:53:50 GMT] [info] [<0.79.0>] 127.0.0.1 - - 'GET' / 200
So maybe it's something platform related. On this particular machine, I am
running:
* Ubuntu Jaunty
* erlang 1:12.b.5-dfsg-2
* libmozjs0d 1.8.1.16+nobinonly-0ubuntu1
(erlang and spidermonkey are both out-of-the-box Ubuntu components)
> Ungraceful behaviour if view returns a function
> ---
>
> Key: COUCHDB-354
> URL: https://issues.apache.org/jira/browse/COUCHDB-354
> Project: CouchDB
> Issue Type: Improvement
> Components: JavaScript View Server
> Environment: {"couchdb":"Welcome","version":"0.10.0a776990"}
>Reporter: Brian Candler
>Priority: Minor
> Attachments: barf.log, test_reduce_barf.rb
>
>
> If a typo in a view definition causes it to return a function instead of a
> normal value:
> * the view server crashes
> * you get a huge Erlang barf in the log with worrying messages like "OS
> process timed out" and "brutal kill"
> I got all this just by accidentally writing "vs.shift" instead of "vs.shift()"
> The fundamental problem is that a function cannot be serialised in toJSON,
> but the error message is not helpful:
> OS Process Log Message: Error converting object to JSON: TypeError:
> {Array:function (v) {var ... snip loads ... "Object"] is not a function
> When actually the problem is that the object I was trying to convert *was* a
> function :-)
> I will attach some code which replicates this, and the barf generated.
> Of course this is entirely down to user error in an invalid map/reduce
> function. However there's already a clean error for 'undefined', maybe this
> could be done for 'function' too (or indeed any non-serialisable entity)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (COUCHDB-354) Ungraceful behaviour if view returns a function
[
https://issues.apache.org/jira/browse/COUCHDB-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Candler reopened COUCHDB-354:
---
> Ungraceful behaviour if view returns a function
> ---
>
> Key: COUCHDB-354
> URL: https://issues.apache.org/jira/browse/COUCHDB-354
> Project: CouchDB
> Issue Type: Improvement
> Components: JavaScript View Server
> Environment: {"couchdb":"Welcome","version":"0.10.0a776990"}
>Reporter: Brian Candler
>Priority: Minor
> Attachments: barf.log, test_reduce_barf.rb
>
>
> If a typo in a view definition causes it to return a function instead of a
> normal value:
> * the view server crashes
> * you get a huge Erlang barf in the log with worrying messages like "OS
> process timed out" and "brutal kill"
> I got all this just by accidentally writing "vs.shift" instead of "vs.shift()"
> The fundamental problem is that a function cannot be serialised in toJSON,
> but the error message is not helpful:
> OS Process Log Message: Error converting object to JSON: TypeError:
> {Array:function (v) {var ... snip loads ... "Object"] is not a function
> When actually the problem is that the object I was trying to convert *was* a
> function :-)
> I will attach some code which replicates this, and the barf generated.
> Of course this is entirely down to user error in an invalid map/reduce
> function. However there's already a clean error for 'undefined', maybe this
> could be done for 'function' too (or indeed any non-serialisable entity)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-354) Ungraceful behaviour if view returns a function
[
https://issues.apache.org/jira/browse/COUCHDB-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711542#action_12711542
]
Brian Candler commented on COUCHDB-354:
---
... and what's more confusing, this error can be in one view, but you get it
when querying a completely different view (because all the views are built at
once). So even if the view server is going to crash, it would be good to know
which view it was building at the time.
> Ungraceful behaviour if view returns a function
> ---
>
> Key: COUCHDB-354
> URL: https://issues.apache.org/jira/browse/COUCHDB-354
> Project: CouchDB
> Issue Type: Improvement
> Components: JavaScript View Server
> Environment: {"couchdb":"Welcome","version":"0.10.0a776990"}
>Reporter: Brian Candler
>Priority: Minor
> Attachments: barf.log, test_reduce_barf.rb
>
>
> If a typo in a view definition causes it to return a function instead of a
> normal value:
> * the view server crashes
> * you get a huge Erlang barf in the log with worrying messages like "OS
> process timed out" and "brutal kill"
> I got all this just by accidentally writing "vs.shift" instead of "vs.shift()"
> The fundamental problem is that a function cannot be serialised in toJSON,
> but the error message is not helpful:
> OS Process Log Message: Error converting object to JSON: TypeError:
> {Array:function (v) {var ... snip loads ... "Object"] is not a function
> When actually the problem is that the object I was trying to convert *was* a
> function :-)
> I will attach some code which replicates this, and the barf generated.
> Of course this is entirely down to user error in an invalid map/reduce
> function. However there's already a clean error for 'undefined', maybe this
> could be done for 'function' too (or indeed any non-serialisable entity)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-354) Ungraceful behaviour if view returns a function
[
https://issues.apache.org/jira/browse/COUCHDB-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Candler updated COUCHDB-354:
--
Attachment: test_reduce_barf.rb
Example where re-reduce function accidentally returns a function instead of an
object
> Ungraceful behaviour if view returns a function
> ---
>
> Key: COUCHDB-354
> URL: https://issues.apache.org/jira/browse/COUCHDB-354
> Project: CouchDB
> Issue Type: Improvement
> Components: JavaScript View Server
> Environment: {"couchdb":"Welcome","version":"0.10.0a776990"}
>Reporter: Brian Candler
>Priority: Minor
> Attachments: barf.log, test_reduce_barf.rb
>
>
> If a typo in a view definition causes it to return a function instead of a
> normal value:
> * the view server crashes
> * you get a huge Erlang barf in the log with worrying messages like "OS
> process timed out" and "brutal kill"
> I got all this just by accidentally writing "vs.shift" instead of "vs.shift()"
> The fundamental problem is that a function cannot be serialised in toJSON,
> but the error message is not helpful:
> OS Process Log Message: Error converting object to JSON: TypeError:
> {Array:function (v) {var ... snip loads ... "Object"] is not a function
> When actually the problem is that the object I was trying to convert *was* a
> function :-)
> I will attach some code which replicates this, and the barf generated.
> Of course this is entirely down to user error in an invalid map/reduce
> function. However there's already a clean error for 'undefined', maybe this
> could be done for 'function' too (or indeed any non-serialisable entity)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-354) Ungraceful behaviour if view returns a function
[
https://issues.apache.org/jira/browse/COUCHDB-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Candler updated COUCHDB-354:
--
Attachment: barf.log
The resulting barf
> Ungraceful behaviour if view returns a function
> ---
>
> Key: COUCHDB-354
> URL: https://issues.apache.org/jira/browse/COUCHDB-354
> Project: CouchDB
> Issue Type: Improvement
> Components: JavaScript View Server
> Environment: {"couchdb":"Welcome","version":"0.10.0a776990"}
>Reporter: Brian Candler
>Priority: Minor
> Attachments: barf.log, test_reduce_barf.rb
>
>
> If a typo in a view definition causes it to return a function instead of a
> normal value:
> * the view server crashes
> * you get a huge Erlang barf in the log with worrying messages like "OS
> process timed out" and "brutal kill"
> I got all this just by accidentally writing "vs.shift" instead of "vs.shift()"
> The fundamental problem is that a function cannot be serialised in toJSON,
> but the error message is not helpful:
> OS Process Log Message: Error converting object to JSON: TypeError:
> {Array:function (v) {var ... snip loads ... "Object"] is not a function
> When actually the problem is that the object I was trying to convert *was* a
> function :-)
> I will attach some code which replicates this, and the barf generated.
> Of course this is entirely down to user error in an invalid map/reduce
> function. However there's already a clean error for 'undefined', maybe this
> could be done for 'function' too (or indeed any non-serialisable entity)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-354) Ungraceful behaviour if view returns a function
Ungraceful behaviour if view returns a function
---
Key: COUCHDB-354
URL: https://issues.apache.org/jira/browse/COUCHDB-354
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Environment: {"couchdb":"Welcome","version":"0.10.0a776990"}
Reporter: Brian Candler
Priority: Minor
If a typo in a view definition causes it to return a function instead of a
normal value:
* the view server crashes
* you get a huge Erlang barf in the log with worrying messages like "OS process
timed out" and "brutal kill"
I got all this just by accidentally writing "vs.shift" instead of "vs.shift()"
The fundamental problem is that a function cannot be serialised in toJSON, but
the error message is not helpful:
OS Process Log Message: Error converting object to JSON: TypeError:
{Array:function (v) {var ... snip loads ... "Object"] is not a function
When actually the problem is that the object I was trying to convert *was* a
function :-)
I will attach some code which replicates this, and the barf generated.
Of course this is entirely down to user error in an invalid map/reduce
function. However there's already a clean error for 'undefined', maybe this
could be done for 'function' too (or indeed any non-serialisable entity)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-336) Would like errors in map function to be reported to client
[
https://issues.apache.org/jira/browse/COUCHDB-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706759#action_12706759
]
Brian Candler commented on COUCHDB-336:
---
Sorry, my mistake for using eval instead of evalcx. The problem seems to be
that evalcx silently catches and discards all errors:
js> evalcx('junk(');
js> evalcx('throw("wobbly")');
js> result = evalcx('throw("wobbly")');
js> typeof result
undefined
js>
I'll ask about this on dev-tech-javascript. At the moment, the only solution I
can see is to eval() inside the evalcx(), which is ugly as it involves
re-escaping the source string.
> Would like errors in map function to be reported to client
> --
>
> Key: COUCHDB-336
> URL: https://issues.apache.org/jira/browse/COUCHDB-336
> Project: CouchDB
> Issue Type: Wish
> Environment: svn trunk 0.10.0a768591
>Reporter: Brian Candler
>Priority: Minor
>
> At the moment, if a runtime error occurs in a map function, the document is
> silently excluded from the view and the client is none the wiser.
> $ curl -X PUT http://127.0.0.1:5984/test
> {"ok":true}
> $ curl -d '{"foo":"bar"}' -X PUT http://127.0.0.1:5984/test/doc1
> {"ok":true,"id":"doc1","rev":"1-3413565576"}
> $ curl -d '{"food":"bar"}' -X PUT http://127.0.0.1:5984/test/doc2
> {"ok":true,"id":"doc2","rev":"1-2088327893"}
> # Example 1: map function calls undefined function
> $ curl -d '{"map":"function(doc) { emitt(null,null); }"}' -H 'Content-Type:
> application/json' -X POST http://127.0.0.1:5984/test/_temp_view
> {"total_rows":0,"rows":[]}
> # Example 2: map function attempts to emit 'undefined'
> $ curl -d '{"map":"function(doc) { emit(doc._id,doc.foo); }"}' -H
> 'Content-Type: application/json' -X POST http://127.0.0.1:5984/test/_temp_view
> {"total_rows":1,"offset":0,"rows":[
> {"id":"doc1","key":"doc1","value":"bar"}
> ]}
> Of course, errors are available in the server log:
> [Tue, 28 Apr 2009 08:40:39 GMT] [info] [<0.1276.0>] OS Process Log Message:
> function raised exception (ReferenceError: emitt is not defined) with doc._id
> doc1
> [Tue, 28 Apr 2009 08:43:44 GMT] [info] [<0.1276.0>] OS Process Log Message:
> function raised exception (Cannot encode 'undefined' value as JSON) with
> doc._id doc2
> But the client cannot see these, and worse, gets what appears to be a valid
> result set.
> I think there are two cases to consider.
> - in temporary views, it ought to be easy to do something: e.g. (1) return
> the full set of failed docs with their errors, or (2) return a count of
> failed docs, or (3) just abort on the first error
> - in permanent views, it might also be useful to return this information, but
> it could be expensive to persist. Also, when you're querying for key X you
> might not want to see a whole load of errors for unrelated docs. An error
> count might be OK though, similar to total_rows.
> The current behaviour may be useful, although I personally wouldn't want to
> rely on it, especially as it generates errors in the log. That is, I would
> rather be forced to rewrite example 2 as
> function(doc) { if (doc.foo) { emit(doc._id, doc.foo); } }
> or
> function(doc) { emit(doc._id, doc.foo || null); }
> as appropriate.
> Workaround: users can manually wrap each of their map functions in a catcher
> which emits a sentinel key/value pair containing the error. However they
> would still have to query the key range which includes the error messages.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-336) Would like errors in map function to be reported to client
[
https://issues.apache.org/jira/browse/COUCHDB-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706742#action_12706742
]
Brian Candler commented on COUCHDB-336:
---
Strange,. When I replicate the logic from compileFunction() at the
spidermonkey command line, it seems to catch the error just fine:
js> sandbox = evalcx('');
[object sandbox]
js> try { f = eval("function(doc){val val=doc.k; emit(val||null,null);}",
sandbox); } catch (err) { print("OOPS: " + err); }
OOPS: SyntaxError: missing ; before statement
js> try { f = eval("function(doc){val val=doc.k; emit(val||null,null);}",
sandbox); } catch (err) { print("OOPS: " + err.toString()); }
OOPS: SyntaxError: missing ; before statement
Maybe a js/spidermonkey expert can explain why this doesn't seem to work in
main.js. Instead it falls through to the later test which checks whether
typeof(functionObject) == "function"
> Would like errors in map function to be reported to client
> --
>
> Key: COUCHDB-336
> URL: https://issues.apache.org/jira/browse/COUCHDB-336
> Project: CouchDB
> Issue Type: Wish
> Environment: svn trunk 0.10.0a768591
>Reporter: Brian Candler
>Priority: Minor
>
> At the moment, if a runtime error occurs in a map function, the document is
> silently excluded from the view and the client is none the wiser.
> $ curl -X PUT http://127.0.0.1:5984/test
> {"ok":true}
> $ curl -d '{"foo":"bar"}' -X PUT http://127.0.0.1:5984/test/doc1
> {"ok":true,"id":"doc1","rev":"1-3413565576"}
> $ curl -d '{"food":"bar"}' -X PUT http://127.0.0.1:5984/test/doc2
> {"ok":true,"id":"doc2","rev":"1-2088327893"}
> # Example 1: map function calls undefined function
> $ curl -d '{"map":"function(doc) { emitt(null,null); }"}' -H 'Content-Type:
> application/json' -X POST http://127.0.0.1:5984/test/_temp_view
> {"total_rows":0,"rows":[]}
> # Example 2: map function attempts to emit 'undefined'
> $ curl -d '{"map":"function(doc) { emit(doc._id,doc.foo); }"}' -H
> 'Content-Type: application/json' -X POST http://127.0.0.1:5984/test/_temp_view
> {"total_rows":1,"offset":0,"rows":[
> {"id":"doc1","key":"doc1","value":"bar"}
> ]}
> Of course, errors are available in the server log:
> [Tue, 28 Apr 2009 08:40:39 GMT] [info] [<0.1276.0>] OS Process Log Message:
> function raised exception (ReferenceError: emitt is not defined) with doc._id
> doc1
> [Tue, 28 Apr 2009 08:43:44 GMT] [info] [<0.1276.0>] OS Process Log Message:
> function raised exception (Cannot encode 'undefined' value as JSON) with
> doc._id doc2
> But the client cannot see these, and worse, gets what appears to be a valid
> result set.
> I think there are two cases to consider.
> - in temporary views, it ought to be easy to do something: e.g. (1) return
> the full set of failed docs with their errors, or (2) return a count of
> failed docs, or (3) just abort on the first error
> - in permanent views, it might also be useful to return this information, but
> it could be expensive to persist. Also, when you're querying for key X you
> might not want to see a whole load of errors for unrelated docs. An error
> count might be OK though, similar to total_rows.
> The current behaviour may be useful, although I personally wouldn't want to
> rely on it, especially as it generates errors in the log. That is, I would
> rather be forced to rewrite example 2 as
> function(doc) { if (doc.foo) { emit(doc._id, doc.foo); } }
> or
> function(doc) { emit(doc._id, doc.foo || null); }
> as appropriate.
> Workaround: users can manually wrap each of their map functions in a catcher
> which emits a sentinel key/value pair containing the error. However they
> would still have to query the key range which includes the error messages.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-336) Would like errors in map function to be reported to client
[
https://issues.apache.org/jira/browse/COUCHDB-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706200#action_12706200
]
Brian Candler commented on COUCHDB-336:
---
As an additional point: the error messages currently returned for a
badly-formed map or reduce function are not as good as the standalone js is
capable of producing. For example:
$ curl -X POST -d '{"map":"function(doc){val val=doc.k;
emit(val||null,null);}"}' http://127.0.0.1:5984/test/_temp_view
{"error":"compilation_error","reason":"expression does not eval to a function.
(function(doc){val val=doc.k; emit(val||null,null);})"}
It's very common for a syntax error to return only "expression does not eval to
a function". However, pasting the same code into js gives a much more
informative error, indicating both the nature of the error and its location.
js> function(doc){val val=doc.k; emit(val||null,null);}
typein:1: SyntaxError: missing ; before statement:
typein:1: function(doc){val val=doc.k; emit(val||null,null);}
typein:1: ..^
> Would like errors in map function to be reported to client
> --
>
> Key: COUCHDB-336
> URL: https://issues.apache.org/jira/browse/COUCHDB-336
> Project: CouchDB
> Issue Type: Wish
> Environment: svn trunk 0.10.0a768591
>Reporter: Brian Candler
>Priority: Minor
>
> At the moment, if a runtime error occurs in a map function, the document is
> silently excluded from the view and the client is none the wiser.
> $ curl -X PUT http://127.0.0.1:5984/test
> {"ok":true}
> $ curl -d '{"foo":"bar"}' -X PUT http://127.0.0.1:5984/test/doc1
> {"ok":true,"id":"doc1","rev":"1-3413565576"}
> $ curl -d '{"food":"bar"}' -X PUT http://127.0.0.1:5984/test/doc2
> {"ok":true,"id":"doc2","rev":"1-2088327893"}
> # Example 1: map function calls undefined function
> $ curl -d '{"map":"function(doc) { emitt(null,null); }"}' -H 'Content-Type:
> application/json' -X POST http://127.0.0.1:5984/test/_temp_view
> {"total_rows":0,"rows":[]}
> # Example 2: map function attempts to emit 'undefined'
> $ curl -d '{"map":"function(doc) { emit(doc._id,doc.foo); }"}' -H
> 'Content-Type: application/json' -X POST http://127.0.0.1:5984/test/_temp_view
> {"total_rows":1,"offset":0,"rows":[
> {"id":"doc1","key":"doc1","value":"bar"}
> ]}
> Of course, errors are available in the server log:
> [Tue, 28 Apr 2009 08:40:39 GMT] [info] [<0.1276.0>] OS Process Log Message:
> function raised exception (ReferenceError: emitt is not defined) with doc._id
> doc1
> [Tue, 28 Apr 2009 08:43:44 GMT] [info] [<0.1276.0>] OS Process Log Message:
> function raised exception (Cannot encode 'undefined' value as JSON) with
> doc._id doc2
> But the client cannot see these, and worse, gets what appears to be a valid
> result set.
> I think there are two cases to consider.
> - in temporary views, it ought to be easy to do something: e.g. (1) return
> the full set of failed docs with their errors, or (2) return a count of
> failed docs, or (3) just abort on the first error
> - in permanent views, it might also be useful to return this information, but
> it could be expensive to persist. Also, when you're querying for key X you
> might not want to see a whole load of errors for unrelated docs. An error
> count might be OK though, similar to total_rows.
> The current behaviour may be useful, although I personally wouldn't want to
> rely on it, especially as it generates errors in the log. That is, I would
> rather be forced to rewrite example 2 as
> function(doc) { if (doc.foo) { emit(doc._id, doc.foo); } }
> or
> function(doc) { emit(doc._id, doc.foo || null); }
> as appropriate.
> Workaround: users can manually wrap each of their map functions in a catcher
> which emits a sentinel key/value pair containing the error. However they
> would still have to query the key range which includes the error messages.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-320) [PATCH] Remove requirement for application/json from _temp_view
[ https://issues.apache.org/jira/browse/COUCHDB-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Candler updated COUCHDB-320: -- Attachment: test-ignore-content-type.js Test case > [PATCH] Remove requirement for application/json from _temp_view > --- > > Key: COUCHDB-320 > URL: https://issues.apache.org/jira/browse/COUCHDB-320 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 0.9 > Environment: svn r762247 >Reporter: Brian Candler >Priority: Minor > Fix For: 0.10 > > Attachments: couchdb-temp-view.patch, test-ignore-content-type.js > > > There is an anomolous check in _temp_view which insists on Content-Type: > application/json > Similar checks elsewhere in the code have already been removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-335) More 500 errors for malformed client requests
[
https://issues.apache.org/jira/browse/COUCHDB-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Candler updated COUCHDB-335:
--
Attachment: error-tests.js
Test cases for errors 1-3 attached.
I'm not sure what you want to return for case 4. Clearly we need the Javascript
compilation error somehow, but I don't think the Erlang barf is needed.
> More 500 errors for malformed client requests
> -
>
> Key: COUCHDB-335
> URL: https://issues.apache.org/jira/browse/COUCHDB-335
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
> Environment: SVN trunk "0.10.0a768591"
>Reporter: Brian Candler
>Priority: Minor
> Attachments: error-tests.js
>
>
> Here are four more cases where malformed client requests can return "500
> Internal Server Error" (as shown by curl -v) with an unhelpful diagnostic
> message.
> $ curl -X PUT http://127.0.0.1:5984/test
> {"ok":true}
> $ curl -X POST -d '{"docs":[1,2,3]}' http://127.0.0.1:5984/test/_bulk_docs
> {"error":"unknown_error","reason":"function_clause"}
> ### 500 Internal Server Error
> $ curl -X POST -d '{"docs":{"foo":"bar"}}'
> http://127.0.0.1:5984/test/_bulk_docs
> {"error":"unknown_error","reason":"function_clause"}
> ### 500 Internal Server Error
> $ curl -X POST -d '[]' -H 'Content-Type: application/json'
> http://127.0.0.1:5984/test/_temp_view
> {"error":"badmatch","reason":""}
> ### 500 Internal Server Error
> $ curl -X POST -d '{}' -H 'Content-Type: application/json'
> http://127.0.0.1:5984/test/_temp_view
> {"error":"badmatch","reason":"{{nocatch,{compilation_error,<<\"expression
> does not eval to a function. (undefined)\">>}},\n
> [{couch_os_process,prompt,2},\n
> {couch_query_servers,'-start_doc_map/2-fun-0-',2},\n {lists,foreach,2},\n
> {couch_query_servers,start_doc_map,2},\n
> {couch_view_updater,view_compute,2},\n {couch_view_updater,update,1}]}"}
> ### 500 Internal Server Error
> See also COUCHDB-320 which gives another way to elicit a 500:
> curl -X POST -d '{"map":"function(){}"}' http://127.0.0.1:5984/test/_temp_view
> {"error":"incorrect_mime_type","reason":"application/x-www-form-urlencoded"}
> ### 500 Internal Server Error
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-336) Would like errors in map function to be reported to client
Would like errors in map function to be reported to client
--
Key: COUCHDB-336
URL: https://issues.apache.org/jira/browse/COUCHDB-336
Project: CouchDB
Issue Type: Wish
Environment: svn trunk 0.10.0a768591
Reporter: Brian Candler
Priority: Minor
At the moment, if a runtime error occurs in a map function, the document is
silently excluded from the view and the client is none the wiser.
$ curl -X PUT http://127.0.0.1:5984/test
{"ok":true}
$ curl -d '{"foo":"bar"}' -X PUT http://127.0.0.1:5984/test/doc1
{"ok":true,"id":"doc1","rev":"1-3413565576"}
$ curl -d '{"food":"bar"}' -X PUT http://127.0.0.1:5984/test/doc2
{"ok":true,"id":"doc2","rev":"1-2088327893"}
# Example 1: map function calls undefined function
$ curl -d '{"map":"function(doc) { emitt(null,null); }"}' -H 'Content-Type:
application/json' -X POST http://127.0.0.1:5984/test/_temp_view
{"total_rows":0,"rows":[]}
# Example 2: map function attempts to emit 'undefined'
$ curl -d '{"map":"function(doc) { emit(doc._id,doc.foo); }"}' -H
'Content-Type: application/json' -X POST http://127.0.0.1:5984/test/_temp_view
{"total_rows":1,"offset":0,"rows":[
{"id":"doc1","key":"doc1","value":"bar"}
]}
Of course, errors are available in the server log:
[Tue, 28 Apr 2009 08:40:39 GMT] [info] [<0.1276.0>] OS Process Log Message:
function raised exception (ReferenceError: emitt is not defined) with doc._id
doc1
[Tue, 28 Apr 2009 08:43:44 GMT] [info] [<0.1276.0>] OS Process Log Message:
function raised exception (Cannot encode 'undefined' value as JSON) with
doc._id doc2
But the client cannot see these, and worse, gets what appears to be a valid
result set.
I think there are two cases to consider.
- in temporary views, it ought to be easy to do something: e.g. (1) return the
full set of failed docs with their errors, or (2) return a count of failed
docs, or (3) just abort on the first error
- in permanent views, it might also be useful to return this information, but
it could be expensive to persist. Also, when you're querying for key X you
might not want to see a whole load of errors for unrelated docs. An error count
might be OK though, similar to total_rows.
The current behaviour may be useful, although I personally wouldn't want to
rely on it, especially as it generates errors in the log. That is, I would
rather be forced to rewrite example 2 as
function(doc) { if (doc.foo) { emit(doc._id, doc.foo); } }
or
function(doc) { emit(doc._id, doc.foo || null); }
as appropriate.
Workaround: users can manually wrap each of their map functions in a catcher
which emits a sentinel key/value pair containing the error. However they would
still have to query the key range which includes the error messages.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-335) More 500 errors for malformed client requests
More 500 errors for malformed client requests
-
Key: COUCHDB-335
URL: https://issues.apache.org/jira/browse/COUCHDB-335
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Environment: SVN trunk "0.10.0a768591"
Reporter: Brian Candler
Priority: Minor
Here are four more cases where malformed client requests can return "500
Internal Server Error" (as shown by curl -v) with an unhelpful diagnostic
message.
$ curl -X PUT http://127.0.0.1:5984/test
{"ok":true}
$ curl -X POST -d '{"docs":[1,2,3]}' http://127.0.0.1:5984/test/_bulk_docs
{"error":"unknown_error","reason":"function_clause"}
### 500 Internal Server Error
$ curl -X POST -d '{"docs":{"foo":"bar"}}' http://127.0.0.1:5984/test/_bulk_docs
{"error":"unknown_error","reason":"function_clause"}
### 500 Internal Server Error
$ curl -X POST -d '[]' -H 'Content-Type: application/json'
http://127.0.0.1:5984/test/_temp_view
{"error":"badmatch","reason":""}
### 500 Internal Server Error
$ curl -X POST -d '{}' -H 'Content-Type: application/json'
http://127.0.0.1:5984/test/_temp_view
{"error":"badmatch","reason":"{{nocatch,{compilation_error,<<\"expression does
not eval to a function. (undefined)\">>}},\n [{couch_os_process,prompt,2},\n
{couch_query_servers,'-start_doc_map/2-fun-0-',2},\n {lists,foreach,2},\n
{couch_query_servers,start_doc_map,2},\n
{couch_view_updater,view_compute,2},\n {couch_view_updater,update,1}]}"}
### 500 Internal Server Error
See also COUCHDB-320 which gives another way to elicit a 500:
curl -X POST -d '{"map":"function(){}"}' http://127.0.0.1:5984/test/_temp_view
{"error":"incorrect_mime_type","reason":"application/x-www-form-urlencoded"}
### 500 Internal Server Error
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
dev@couchdb.apache.org
[ https://issues.apache.org/jira/browse/COUCHDB-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Candler updated COUCHDB-331: -- Attachment: test-reduce.diff Test case > Allow reduce=true&include_docs=false > > > Key: COUCHDB-331 > URL: https://issues.apache.org/jira/browse/COUCHDB-331 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface > Environment: 0.10.0a767851 >Reporter: Brian Candler >Priority: Trivial > Attachments: test-reduce.diff > > > If you query to a map/reduce view, then currently a request for > reduce=true&include_docs=false > is rejected as erroneous. > It would be useful to allow this, to simplify clients which remember default > options for a view (e.g. :reduce=>false,:include_docs=>true) and then > override them for particular queries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-332) Reject documents whose ids start with underscore
Reject documents whose ids start with underscore
Key: COUCHDB-332
URL: https://issues.apache.org/jira/browse/COUCHDB-332
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Environment: 0.10.0a767851
Reporter: Brian Candler
Priority: Minor
docids which start with underscore are reserved for CouchDB. I believe they
should be rejected to avoid confusion.
Currently observed behaviour:
(1) an attempt to PUT to /db/_docid succeeds, and creates a document whose ID
starts with an underscore
$ curl -X PUT -d "{}" http://127.0.0.1:5984/foo/_xxx
{"ok":true,"id":"_xxx","rev":"1-1751372641"}
(2) a POST to /db/_docid tries to do something and fails; possibly it could
succeed given the right headers and body.
$ curl -X POST -d "{}" http://127.0.0.1:5984/foo/_yyy
{"error":"bad_content_type","reason":"Invalid Content-Type header for form
upload"}
-- status line show 415 Unsupported Media Type
This means that typos can result in confusing error messages; for example, a
POST to /db/_tmp_view instead of /db/_temp_view. IMO it would be cleaner first
to test the docid and reject it on that basis.
(Sorry, I am not including a test suite submission. It will be much easier for
someone who already knows their way around the rather large set of private
libraries which the test suite contains. I currently use Ruby to talk to
CouchDB, not ECMAscript)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
dev@couchdb.apache.org
Allow reduce=true&include_docs=false Key: COUCHDB-331 URL: https://issues.apache.org/jira/browse/COUCHDB-331 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Environment: 0.10.0a767851 Reporter: Brian Candler Priority: Trivial If you query to a map/reduce view, then currently a request for reduce=true&include_docs=false is rejected as erroneous. It would be useful to allow this, to simplify clients which remember default options for a view (e.g. :reduce=>false,:include_docs=>true) and then override them for particular queries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (COUCHDB-306) Wacky error responses to malformed documents
[
https://issues.apache.org/jira/browse/COUCHDB-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Candler reopened COUCHDB-306:
---
Examples 1, 4 and 5 now give sensible errors in the body, and example 2 gives a
405 Method Not Allowed response (albeit with an empty body). These are fine.
However example 3 still gives its perplexing response:
$ curl http://127.0.0.1:5984/
{"couchdb":"Welcome","version":"0.9.0a766377"}
-- example 3
$ curl -d "{}" -X POST http://127.0.0.1:5984/foo/bar
{"error":"badmatch","reason":"{\"application/x-www-form-urlencoded\",[]}"}
$ curl -d "{}" -H "Content-Type: application/json" -X POST
http://127.0.0.1:5984/foo/bar
{"error":"badmatch","reason":"{\"application/json\",[]}"}
Both are with a 500 Internal Server Error
I think a 405 would be more appropriate. The error is that the user tried to
POST rather than PUT to update an attachment.
> Wacky error responses to malformed documents
>
>
> Key: COUCHDB-306
> URL: https://issues.apache.org/jira/browse/COUCHDB-306
> Project: CouchDB
> Issue Type: Improvement
>Affects Versions: 0.9
>Reporter: Brian Candler
>Assignee: Paul Joseph Davis
>Priority: Minor
> Fix For: 0.9.1, 0.10
>
>
> Here are some error conditions where CouchDB provides very strange responses.
> Setup
> $ curl -X PUT http://127.0.0.1:5984/foo
> {"ok":true}
> example 1
> $ curl -d "[]" -X PUT http://127.0.0.1:5984/foo/bar
> {"error":"bad_request","reason":[68,111,99,117,109,101,110,116,32,109,117,115,116,32,98,101,32,97,32,74,83,79,78,32,111,98,106,101,99,116]}
> example 2
> $ curl -d "[]" -X PUT http://127.0.0.1:5984/foo/_bulk_docs
> -- TCP connection is dropped on the floor, no response (not even HTTP 500
> status)
> example 3
> $ curl -d "{}" -X POST http://127.0.0.1:5984/foo/bar
> {"error":"badmatch","reason":"{\"application/x-www-form-urlencoded\",[]}"}
> $ curl -d "{}" -H "Content-Type: application/json" -X POST
> http://127.0.0.1:5984/foo/bar
> {"error":"badmatch","reason":"{\"application/json\",[]}"}
> example 4
> $ curl -d '[]' -X POST http://127.0.0.1:5984/foo/_all_docs
> {"error":"badmatch","reason":""}
> example 5
> $ curl -d '{"keys":"foo"}' -X POST http://127.0.0.1:5984/foo/_all_docs
> {"error":"unknown_error","reason":"function_clause"}
> Of course, all of these are misuse of the API, but they may be seen by
> newcomers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COUCHDB-324) startkey and endkey don't work with ~ or %7E
[
https://issues.apache.org/jira/browse/COUCHDB-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Candler resolved COUCHDB-324.
---
Resolution: Invalid
This is expected behaviour from the Unicode Collation Algorithm. I have added
some notes on this to
http://wiki.apache.org/couchdb/View_collation
> startkey and endkey don't work with ~ or %7E
>
>
> Key: COUCHDB-324
> URL: https://issues.apache.org/jira/browse/COUCHDB-324
> Project: CouchDB
> Issue Type: Bug
> Environment: svn -r763553
>Reporter: Brian Candler
>
> The following range queries don't work as expected
> startkey="a"&endkey="a~"
> startkey="a"&endkey="a%7E"
> (Aside: I was hoping to use "foo" to "foo~" as a reasonably clean way of
> querying "any key beginning with foo")
> The following testcase shows this for "a~", since query doesn't encode it.
> However I wasn't sure how to test for "a%7E" cleanly.
> --- /home/brian/svn/couchdb/share/www/script/test/view_collation.js
> 2009-03-20 12:50:46.0 +
> +++ view_collation.js 2009-04-09 11:23:20.0 +0100
> @@ -109,4 +109,11 @@
> endkey : "b", endkey_docid: "b",
> inclusive_end:false}).rows;
>T(rows[rows.length-1].key == "aa")
> +
> + // startkey and endkey with ~ (currently query doesn't encode this,
> + // but really we should test both a~ and a%7E)
> + var rows = db.query(queryFun, null, {startkey: "a", endkey: "a~"}).rows;
> + T(rows.length == 3); // a, A, aa
> + var rows = db.query(queryFun, null, {startkey: "a~", endkey: "b"}).rows;
> + T(rows.length == 1 && rows[0].key == "b");
> };
> Here are the actual results obtained using curl:
> $ curl -X POST -d '{"map":"function(doc) { emit(doc.foo, null); }"}'
> 'http://127.0.0.1:5984/test_suite_db/_temp_view?startkey="a"&endkey="a~";'
> {"total_rows":26,"offset":7,"rows":[
> {"id":"7","key":"a","value":null},
> {"id":"8","key":"A","value":null}
> ]}
> $ curl -X POST -d '{"map":"function(doc) { emit(doc.foo, null); }"}'
> 'http://127.0.0.1:5984/test_suite_db/_temp_view?startkey="a"&endkey="a%7E";'
> {"total_rows":26,"offset":7,"rows":[
> {"id":"7","key":"a","value":null},
> {"id":"8","key":"A","value":null}
> ]}
> But what I was expecting was the same as range "a" to "az":
> $ curl -X POST -d '{"map":"function(doc) { emit(doc.foo, null); }"}'
> 'http://127.0.0.1:5984/test_suite_db/_temp_view?startkey="a"&endkey="az";'
> {"total_rows":26,"offset":7,"rows":[
> {"id":"7","key":"a","value":null},
> {"id":"8","key":"A","value":null},
> {"id":"9","key":"aa","value":null}
> ]}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-324) startkey and endkey don't work with ~ or %7E
startkey and endkey don't work with ~ or %7E
Key: COUCHDB-324
URL: https://issues.apache.org/jira/browse/COUCHDB-324
Project: CouchDB
Issue Type: Bug
Environment: svn -r763553
Reporter: Brian Candler
The following range queries don't work as expected
startkey="a"&endkey="a~"
startkey="a"&endkey="a%7E"
(Aside: I was hoping to use "foo" to "foo~" as a reasonably clean way of
querying "any key beginning with foo")
The following testcase shows this for "a~", since query doesn't encode it.
However I wasn't sure how to test for "a%7E" cleanly.
--- /home/brian/svn/couchdb/share/www/script/test/view_collation.js
2009-03-20 12:50:46.0 +
+++ view_collation.js 2009-04-09 11:23:20.0 +0100
@@ -109,4 +109,11 @@
endkey : "b", endkey_docid: "b",
inclusive_end:false}).rows;
T(rows[rows.length-1].key == "aa")
+
+ // startkey and endkey with ~ (currently query doesn't encode this,
+ // but really we should test both a~ and a%7E)
+ var rows = db.query(queryFun, null, {startkey: "a", endkey: "a~"}).rows;
+ T(rows.length == 3); // a, A, aa
+ var rows = db.query(queryFun, null, {startkey: "a~", endkey: "b"}).rows;
+ T(rows.length == 1 && rows[0].key == "b");
};
Here are the actual results obtained using curl:
$ curl -X POST -d '{"map":"function(doc) { emit(doc.foo, null); }"}'
'http://127.0.0.1:5984/test_suite_db/_temp_view?startkey="a"&endkey="a~";'
{"total_rows":26,"offset":7,"rows":[
{"id":"7","key":"a","value":null},
{"id":"8","key":"A","value":null}
]}
$ curl -X POST -d '{"map":"function(doc) { emit(doc.foo, null); }"}'
'http://127.0.0.1:5984/test_suite_db/_temp_view?startkey="a"&endkey="a%7E";'
{"total_rows":26,"offset":7,"rows":[
{"id":"7","key":"a","value":null},
{"id":"8","key":"A","value":null}
]}
But what I was expecting was the same as range "a" to "az":
$ curl -X POST -d '{"map":"function(doc) { emit(doc.foo, null); }"}'
'http://127.0.0.1:5984/test_suite_db/_temp_view?startkey="a"&endkey="az";'
{"total_rows":26,"offset":7,"rows":[
{"id":"7","key":"a","value":null},
{"id":"8","key":"A","value":null},
{"id":"9","key":"aa","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-302) Permissions problems under Ubuntu
[
https://issues.apache.org/jira/browse/COUCHDB-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Candler closed COUCHDB-302.
-
Resolution: Fixed
The "1: 0" error was reported separately as COUCHDB-305 and fixed
The pidfile was moved recently to .../var/run/couchdb/ directory (r761355) and
the README updated to indicate that this directory needs to be created with the
correct permissions (r761352)
> Permissions problems under Ubuntu
> -
>
> Key: COUCHDB-302
> URL: https://issues.apache.org/jira/browse/COUCHDB-302
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.9
> Environment: r757147
> Ubuntu Hardy
>Reporter: Brian Candler
>
> Couchdb install scripts not setting correct permissions under Ubuntu. First I
> did a complete wipe of all couchdb-related files and directories:
> $ sudo rm -rf /usr/local/var/lib/couchdb
> $ sudo rm -rf /usr/local/lib/couchdb /usr/local/share/couchdb
> /usr/local/var/log/couchdb /usr/local/var/run/couchdb.pid
> /usr/local/etc/init.d/couchdb /usr/local/etc/logrotate.d/couchdb
> /usr/local/etc/default/couchdb /usr/local/bin/couch{db,js}
> Then after a 'make install':
> $ sudo /usr/local/etc/init.d/couchdb start
> * Starting database server couchdb
> Apache CouchDB needs write permission on the PID file:
> /usr/local/var/run/couchdb.pid
>
> [fail]
> So I created the pidfile by hand:
> $ sudo touch /usr/local/var/run/couchdb.pid
> $ sudo chown couchdb:couchdb /usr/local/var/run/couchdb.pid
> $ sudo /usr/local/etc/init.d/couchdb start
> * Starting database server couchdb
> /usr/local/bin/couchdb: 1: 0: not found
> /usr/local/bin/couchdb: 1: 0: not found
> /usr/local/bin/couchdb: 1: 0: not found
> [ OK
> ]
> Despite the "not found" errors, couchdb was running. Now:
> $ curl -X PUT http://localhost:5984/db1
> {"error":"error","reason":"eacces"}
> I found that /usr/local/var/lib/couchdb had been recreated with owner 0:0
> It seems to work OK after this:
> $ sudo chown couchdb:couchdb /usr/local/var/lib/couchdb
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-320) [PATCH] Remove requirement for application/json from _temp_view
[ https://issues.apache.org/jira/browse/COUCHDB-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Candler updated COUCHDB-320: -- Attachment: couchdb-temp-view.patch > [PATCH] Remove requirement for application/json from _temp_view > --- > > Key: COUCHDB-320 > URL: https://issues.apache.org/jira/browse/COUCHDB-320 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 0.9 > Environment: svn r762247 >Reporter: Brian Candler >Priority: Minor > Fix For: 0.10 > > Attachments: couchdb-temp-view.patch > > > There is an anomolous check in _temp_view which insists on Content-Type: > application/json > Similar checks elsewhere in the code have already been removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-320) [PATCH] Remove requirement for application/json from _temp_view
[PATCH] Remove requirement for application/json from _temp_view --- Key: COUCHDB-320 URL: https://issues.apache.org/jira/browse/COUCHDB-320 Project: CouchDB Issue Type: Improvement Affects Versions: 0.9 Environment: svn r762247 Reporter: Brian Candler Priority: Minor Fix For: 0.10 There is an anomolous check in _temp_view which insists on Content-Type: application/json Similar checks elsewhere in the code have already been removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-317) Badmatch error if _replicate target starts with slash
Badmatch error if _replicate target starts with slash
-
Key: COUCHDB-317
URL: https://issues.apache.org/jira/browse/COUCHDB-317
Project: CouchDB
Issue Type: Bug
Affects Versions: 0.9.1
Environment: svn r761188
Reporter: Brian Candler
Priority: Trivial
Giving a replication source or target which starts with a slash gives an Erlang
barf error. (The wiki at http://wiki.apache.org/couchdb/Replication said that
this slash was necessary. I will fix the wiki, but the error is still unsightly)
$ curl -X POST -d '{"source":"/foo","target":"/bar"}'
http://127.0.0.1:5984/_replicate
{"error":"case_clause","reason":"{error,{{{badmatch,{error,illegal_database_name}},\n
[{couch_rep,init,1},\n {gen_server,init_it,6},\n
{proc_lib,init_p,5}]},\n
{child,undefined,\"7898c2bfbbcf8adbb305371e6c3c949e\",\n
{gen_server,start_link,\n [couch_rep,\n
[\"7898c2bfbbcf8adbb305371e6c3c949e\",\n
{local,<<\"/foo\">>,{user_ctx,null,[<<\"_admin\">>]}},\n
{local,<<\"/bar\">>,\n
{user_ctx,null,[<<\"_admin\">>]}}],\n[]]},\n
transient,1,worker,\n [couch_rep]}}}"}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-313) '$' in database name confuses behaviour of %2F in design doc ID
'$' in database name confuses behaviour of %2F in design doc ID
---
Key: COUCHDB-313
URL: https://issues.apache.org/jira/browse/COUCHDB-313
Project: CouchDB
Issue Type: Bug
Affects Versions: 0.9
Environment: svn r761188
Ubuntu Hardy + Erlang 12B3 from Intrepid
Reporter: Brian Candler
Priority: Minor
Normally, if you use %2F to separate _design from the rest of the URL, you get
a 301 redirect:
$ curl -X PUT http://127.0.0.1:5984/mydb
{"ok":true}
$ curl -X PUT -d"{}" http://127.0.0.1:5984/mydb/_design/test
{"ok":true,"id":"_design/test","rev":"1-481559718"}
$ curl -v http://127.0.0.1:5984/mydb/_design%2Ftest
...
< HTTP/1.1 301 Moved Permanently
< Server: CouchDB/0.9.0 (Erlang OTP/R12B)
< Location: http://127.0.0.1:5984/mydb/_design/test
However this logic is broken if you use a database which has a '$' in the name:
you get a 'badmatch' erlang error.
$ curl -X PUT 'http://127.0.0.1:5984/my$db'
{"ok":true}
$ curl -X PUT -d'{}' 'http://127.0.0.1:5984/my$db/_design/test'
{"ok":true,"id":"_design/test","rev":"1-4187139805"}
$ curl 'http://127.0.0.1:5984/my$db/_design/test'
{"_id":"_design/test","_rev":"1-4187139805"}
$ curl 'http://127.0.0.1:5984/my$db/_design%2Ftest'
{"error":"badmatch","reason":"{ok,[\"/my$db/\",\"test\"]}"}
$ is allowed in a database name according to the wiki (as long as it's not the
first character), and otherwise appears to work OK. I have not tried other
'unusual' characters.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-306) Wacky error responses to malformed documents
Wacky error responses to malformed documents
Key: COUCHDB-306
URL: https://issues.apache.org/jira/browse/COUCHDB-306
Project: CouchDB
Issue Type: Improvement
Affects Versions: 0.9
Reporter: Brian Candler
Priority: Minor
Here are some error conditions where CouchDB provides very strange responses.
Setup
$ curl -X PUT http://127.0.0.1:5984/foo
{"ok":true}
example 1
$ curl -d "[]" -X PUT http://127.0.0.1:5984/foo/bar
{"error":"bad_request","reason":[68,111,99,117,109,101,110,116,32,109,117,115,116,32,98,101,32,97,32,74,83,79,78,32,111,98,106,101,99,116]}
example 2
$ curl -d "[]" -X PUT http://127.0.0.1:5984/foo/_bulk_docs
-- TCP connection is dropped on the floor, no response (not even HTTP 500
status)
example 3
$ curl -d "{}" -X POST http://127.0.0.1:5984/foo/bar
{"error":"badmatch","reason":"{\"application/x-www-form-urlencoded\",[]}"}
$ curl -d "{}" -H "Content-Type: application/json" -X POST
http://127.0.0.1:5984/foo/bar
{"error":"badmatch","reason":"{\"application/json\",[]}"}
example 4
$ curl -d '[]' -X POST http://127.0.0.1:5984/foo/_all_docs
{"error":"badmatch","reason":""}
example 5
$ curl -d '{"keys":"foo"}' -X POST http://127.0.0.1:5984/foo/_all_docs
{"error":"unknown_error","reason":"function_clause"}
Of course, all of these are misuse of the API, but they may be seen by
newcomers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-302) Permissions problems under Ubuntu
[
https://issues.apache.org/jira/browse/COUCHDB-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688285#action_12688285
]
Brian Candler commented on COUCHDB-302:
---
Fix for the "1: 0: not found" errors:
--- bin/couchdb.tpl.in (revision 757393)
+++ bin/couchdb.tpl.in (working copy)
@@ -140,15 +140,15 @@
exit $SCRIPT_ERROR
fi
message_prefix="Apache CouchDB needs a regular"
-if `echo 2> /dev/null >> $PID_FILE; echo $?` -gt 0; then
+if test `echo 2> /dev/null >> $PID_FILE; echo $?` -gt 0; then
echo "$message_prefix PID file: $PID_FILE" >&2
exit $SCRIPT_ERROR
fi
-if `echo 2> /dev/null >> $STDOUT_FILE; echo $?` -gt 0; then
+if test `echo 2> /dev/null >> $STDOUT_FILE; echo $?` -gt 0; then
echo "$message_prefix STDOUT file: $STDOUT_FILE" >&2
exit $SCRIPT_ERROR
fi
-if `echo 2> /dev/null >> $STDERR_FILE; echo $?` -gt 0; then
+if test `echo 2> /dev/null >> $STDERR_FILE; echo $?` -gt 0; then
echo "$message_prefix STDERR file: $STDERR_FILE" >&2
exit $SCRIPT_ERROR
fi
I notice that the README tells you to chown the /usr/local/var/lib/couchdb and
/usr/local/var/log/couchdb directories. IMO this would be better done
automatically by 'make install'.
Suggested fix for pidfile permission errors: move the pidfile into a
/usr/local/var/run/couchdb/ directory with correct ownership. (This would then
be a third directory which needs to be created correctly). Or else into the log
directory.
--- bin/couchdb.tpl.in (revision 757393)
+++ bin/couchdb.tpl.in (working copy)
@@ -27,7 +27,7 @@
DEFAULT_INI_FILE=%localconfdir%/%defaultini%
LOCAL_INI_FILE=%localconfdir%/%localini%
-PID_FILE=%localstatedir%/run/couchdb.pid
+PID_FILE=%localstatedir%/run/couchdb/couchdb.pid
STDOUT_FILE=couchdb.stdout
STDERR_FILE=couchdb.stderr
> Permissions problems under Ubuntu
> -
>
> Key: COUCHDB-302
> URL: https://issues.apache.org/jira/browse/COUCHDB-302
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.9
> Environment: r757147
> Ubuntu Hardy
>Reporter: Brian Candler
>
> Couchdb install scripts not setting correct permissions under Ubuntu. First I
> did a complete wipe of all couchdb-related files and directories:
> $ sudo rm -rf /usr/local/var/lib/couchdb
> $ sudo rm -rf /usr/local/lib/couchdb /usr/local/share/couchdb
> /usr/local/var/log/couchdb /usr/local/var/run/couchdb.pid
> /usr/local/etc/init.d/couchdb /usr/local/etc/logrotate.d/couchdb
> /usr/local/etc/default/couchdb /usr/local/bin/couch{db,js}
> Then after a 'make install':
> $ sudo /usr/local/etc/init.d/couchdb start
> * Starting database server couchdb
> Apache CouchDB needs write permission on the PID file:
> /usr/local/var/run/couchdb.pid
>
> [fail]
> So I created the pidfile by hand:
> $ sudo touch /usr/local/var/run/couchdb.pid
> $ sudo chown couchdb:couchdb /usr/local/var/run/couchdb.pid
> $ sudo /usr/local/etc/init.d/couchdb start
> * Starting database server couchdb
> /usr/local/bin/couchdb: 1: 0: not found
> /usr/local/bin/couchdb: 1: 0: not found
> /usr/local/bin/couchdb: 1: 0: not found
> [ OK
> ]
> Despite the "not found" errors, couchdb was running. Now:
> $ curl -X PUT http://localhost:5984/db1
> {"error":"error","reason":"eacces"}
> I found that /usr/local/var/lib/couchdb had been recreated with owner 0:0
> It seems to work OK after this:
> $ sudo chown couchdb:couchdb /usr/local/var/lib/couchdb
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-302) Permissions problems under Ubuntu
Permissions problems under Ubuntu
-
Key: COUCHDB-302
URL: https://issues.apache.org/jira/browse/COUCHDB-302
Project: CouchDB
Issue Type: Bug
Affects Versions: 0.9
Environment: r757147
Ubuntu Hardy
Reporter: Brian Candler
Couchdb install scripts not setting correct permissions under Ubuntu. First I
did a complete wipe of all couchdb-related files and directories:
$ sudo rm -rf /usr/local/var/lib/couchdb
$ sudo rm -rf /usr/local/lib/couchdb /usr/local/share/couchdb
/usr/local/var/log/couchdb /usr/local/var/run/couchdb.pid
/usr/local/etc/init.d/couchdb /usr/local/etc/logrotate.d/couchdb
/usr/local/etc/default/couchdb /usr/local/bin/couch{db,js}
Then after a 'make install':
$ sudo /usr/local/etc/init.d/couchdb start
* Starting database server couchdb
Apache CouchDB needs write permission on the PID file:
/usr/local/var/run/couchdb.pid
[fail]
So I created the pidfile by hand:
$ sudo touch /usr/local/var/run/couchdb.pid
$ sudo chown couchdb:couchdb /usr/local/var/run/couchdb.pid
$ sudo /usr/local/etc/init.d/couchdb start
* Starting database server couchdb
/usr/local/bin/couchdb: 1: 0: not found
/usr/local/bin/couchdb: 1: 0: not found
/usr/local/bin/couchdb: 1: 0: not found
[ OK ]
Despite the "not found" errors, couchdb was running. Now:
$ curl -X PUT http://localhost:5984/db1
{"error":"error","reason":"eacces"}
I found that /usr/local/var/lib/couchdb had been recreated with owner 0:0
It seems to work OK after this:
$ sudo chown couchdb:couchdb /usr/local/var/lib/couchdb
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-299) Futon cannot display map-only views
[ https://issues.apache.org/jira/browse/COUCHDB-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683887#action_12683887 ] Brian Candler commented on COUCHDB-299: --- D'oh. Shift-reload fixed it. Thank you. (Aside: the script has a slug but it's only the next release version number: script/futon.js?0.9.0 - maybe SVN rev would be better? But not a problem now I know what to do) > Futon cannot display map-only views > --- > > Key: COUCHDB-299 > URL: https://issues.apache.org/jira/browse/COUCHDB-299 > Project: CouchDB > Issue Type: Bug > Components: Administration Console >Affects Versions: 0.9 > Environment: CouchDB SVN r756437 > Ubuntu Hardy > Standard Firefox 3.0.7+nobinonly-0ubuntu0.8.04.1 >Reporter: Brian Candler > > If you have a map-only view, Futon is no longer able to display it, instead > showing an error dialog: > "Error: query_parse_error > Query parameter "group" and/or "group_level" are invalid for map views." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-299) Futon cannot display map-only views
[ https://issues.apache.org/jira/browse/COUCHDB-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Candler closed COUCHDB-299. - Resolution: Invalid > Futon cannot display map-only views > --- > > Key: COUCHDB-299 > URL: https://issues.apache.org/jira/browse/COUCHDB-299 > Project: CouchDB > Issue Type: Bug > Components: Administration Console >Affects Versions: 0.9 > Environment: CouchDB SVN r756437 > Ubuntu Hardy > Standard Firefox 3.0.7+nobinonly-0ubuntu0.8.04.1 >Reporter: Brian Candler > > If you have a map-only view, Futon is no longer able to display it, instead > showing an error dialog: > "Error: query_parse_error > Query parameter "group" and/or "group_level" are invalid for map views." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-299) Futon cannot display map-only views
Futon cannot display map-only views --- Key: COUCHDB-299 URL: https://issues.apache.org/jira/browse/COUCHDB-299 Project: CouchDB Issue Type: Bug Components: Administration Console Affects Versions: 0.9 Environment: CouchDB SVN r756437 Ubuntu Hardy Standard Firefox 3.0.7+nobinonly-0ubuntu0.8.04.1 Reporter: Brian Candler If you have a map-only view, Futon is no longer able to display it, instead showing an error dialog: "Error: query_parse_error Query parameter "group" and/or "group_level" are invalid for map views." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-298) Document vanishes from view after attempted update
[ https://issues.apache.org/jira/browse/COUCHDB-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Candler updated COUCHDB-298: -- Attachment: view2.sh Script to replicate problem > Document vanishes from view after attempted update > -- > > Key: COUCHDB-298 > URL: https://issues.apache.org/jira/browse/COUCHDB-298 > Project: CouchDB > Issue Type: Bug > Components: Database Core > Environment: CouchDB SVN r756437 > Ubuntu Hardy (but with Erlang 1:12.b.3-dfsg-1ubuntu1 from Ubuntu Intrepid) >Reporter: Brian Candler >Priority: Blocker > Attachments: view2.sh > > > If you attempt to make an update to a doc with an old _rev, and hence it is > rejected with a 409, the document drops out of [at least some] views. > I have a shell script which replicates this problem reliably. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-298) Document vanishes from view after attempted update
Document vanishes from view after attempted update -- Key: COUCHDB-298 URL: https://issues.apache.org/jira/browse/COUCHDB-298 Project: CouchDB Issue Type: Bug Components: Database Core Environment: CouchDB SVN r756437 Ubuntu Hardy (but with Erlang 1:12.b.3-dfsg-1ubuntu1 from Ubuntu Intrepid) Reporter: Brian Candler Priority: Blocker If you attempt to make an update to a doc with an old _rev, and hence it is rejected with a 409, the document drops out of [at least some] views. I have a shell script which replicates this problem reliably. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-235) Doesn't gracefully handle malformed URLs
Doesn't gracefully handle malformed URLs Key: COUCHDB-235 URL: https://issues.apache.org/jira/browse/COUCHDB-235 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.9 Environment: CentOS 5.2, Ubuntu Hardy couchdb - Apache CouchDB 0.9.0a739811-incubating Reporter: Brian Candler Priority: Minor This one took me a while to track down, and Couchdb could have helped me more :-) If you use curl to submit a request which includes a space, couchdb drops the connection on the floor: no response whatsoever, and nothing in logs. e.g. $ curl 'http://localhost:5984/test_suite_db/_a_view/foo/bar?key="one two"' curl: (52) Empty reply from server When you check with tcpdump, it turns out that curl is not URL-encoding the space, but passing it straight through: ... 0x0030: 0e38 b57c 4745 5420 2f74 6573 745f 7375 .8.|GET./test_su 0x0040: 6974 655f 6462 2f5f 615f 7669 6577 2f66 ite_db/_a_view/f 0x0050: 6f6f 2f62 6172 3f6b 6579 3d22 6f6e 6520 oo/bar?key="one. 0x0060: 7477 6f22 2048 5454 502f 312e 310d 0a55 two".HTTP/1.1..U 0x0070: 7365 722d 4167 656e 743a 2063 7572 6c2f ser-Agent:.curl/ 0x0080: 372e 3135 2e35 2028 6936 3836 2d72 6564 7.15.5.(i686-red 0x0090: 6861 742d 6c69 6e75 782d 676e 7529 206c hat-linux-gnu).l ... This happens with both versions of curl I tried (7.15.5 from CentOS 5.2, and 7.18.0 from Ubuntu Hardy) This is arguably a bug in curl: it should either encode the space or reject the whole URL. However, I wonder if couchdb could be a little more forgiving in this case, and at least return some sort of error to the client, like a 400 Bad Request. For comparison: under the same circumstances, Apache (2.2.8) actually accepts and processes the request, just giving a 404 if the document isn't found. The BNF in RFC 2616 says: Request-Line = Method SP Request-URI SP HTTP-Version CRLF RFC 1738 says that space is unsafe, and unsafe characters MUST be encoded in URLs. So Couchdb is within its rights to reject it - it would just be helpful if it could give an error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-234) [PATCH] Improved Accept/Content-Type negotiation
[PATCH] Improved Accept/Content-Type negotiation Key: COUCHDB-234 URL: https://issues.apache.org/jira/browse/COUCHDB-234 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.9 Reporter: Brian Candler Priority: Minor Attachments: couchdb-mime.diff Suggested improvement for Content-Type of responses Return Content-Type: application/json unless: * client provides an Accept: header; and * header includes text/plain, text/* or */*; and * header does not have application/json earlier in the list This is not proper RFC 2616 negotiation - q factors are ignored - but maybe it's better than current behaviour. Tested with Firefox (which still views responses as text), but not other browsers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-234) [PATCH] Improved Accept/Content-Type negotiation
[ https://issues.apache.org/jira/browse/COUCHDB-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Candler updated COUCHDB-234: -- Attachment: couchdb-mime.diff > [PATCH] Improved Accept/Content-Type negotiation > > > Key: COUCHDB-234 > URL: https://issues.apache.org/jira/browse/COUCHDB-234 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 0.9 >Reporter: Brian Candler >Priority: Minor > Attachments: couchdb-mime.diff > > > Suggested improvement for Content-Type of responses > Return Content-Type: application/json unless: > * client provides an Accept: header; and > * header includes text/plain, text/* or */*; and > * header does not have application/json earlier in the list > This is not proper RFC 2616 negotiation - q factors are ignored - but maybe > it's better than current behaviour. Tested with Firefox (which still views > responses as text), but not other browsers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
