[jira] [Updated] (COUCHDB-1288) More efficient builtin filters _doc_ids and _design
[ https://issues.apache.org/jira/browse/COUCHDB-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana updated COUCHDB-1288: --- Attachment: (was: couchdb_1288_2.patch) More efficient builtin filters _doc_ids and _design --- Key: COUCHDB-1288 URL: https://issues.apache.org/jira/browse/COUCHDB-1288 Project: CouchDB Issue Type: Improvement Reporter: Filipe Manana Attachments: couchdb_1288.patch We have the _doc_ids and _design _changes filter as of CouchDB 1.1.0. While they meet the expectations of applications/users, they're far from efficient for large databases. Basically the implementation folds the entire seq btree and then filters values by the document's ID, causing too much IO and busting caches. This makes replication by doc IDs not so efficient as it could be. The proposed patch avoids this by doing direct lookups in the ID btree, for _doc_ids, and ranged fold for _design. If there are no objections, I would apply to branch 1.2.x besides -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1288) More efficient builtin filters _doc_ids and _design
[ https://issues.apache.org/jira/browse/COUCHDB-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana updated COUCHDB-1288: --- Attachment: couchdb_1288_2.patch More efficient builtin filters _doc_ids and _design --- Key: COUCHDB-1288 URL: https://issues.apache.org/jira/browse/COUCHDB-1288 Project: CouchDB Issue Type: Improvement Reporter: Filipe Manana Attachments: couchdb_1288_2.patch We have the _doc_ids and _design _changes filter as of CouchDB 1.1.0. While they meet the expectations of applications/users, they're far from efficient for large databases. Basically the implementation folds the entire seq btree and then filters values by the document's ID, causing too much IO and busting caches. This makes replication by doc IDs not so efficient as it could be. The proposed patch avoids this by doing direct lookups in the ID btree, for _doc_ids, and ranged fold for _design. If there are no objections, I would apply to branch 1.2.x besides -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1288) More efficient builtin filters _doc_ids and _design
[ https://issues.apache.org/jira/browse/COUCHDB-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana updated COUCHDB-1288: --- Attachment: (was: couchdb_1288.patch) More efficient builtin filters _doc_ids and _design --- Key: COUCHDB-1288 URL: https://issues.apache.org/jira/browse/COUCHDB-1288 Project: CouchDB Issue Type: Improvement Reporter: Filipe Manana Attachments: couchdb_1288_2.patch We have the _doc_ids and _design _changes filter as of CouchDB 1.1.0. While they meet the expectations of applications/users, they're far from efficient for large databases. Basically the implementation folds the entire seq btree and then filters values by the document's ID, causing too much IO and busting caches. This makes replication by doc IDs not so efficient as it could be. The proposed patch avoids this by doing direct lookups in the ID btree, for _doc_ids, and ranged fold for _design. If there are no objections, I would apply to branch 1.2.x besides -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1288) More efficient builtin filters _doc_ids and _design
[ https://issues.apache.org/jira/browse/COUCHDB-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107653#comment-13107653 ] Filipe Manana commented on COUCHDB-1288: This still needs some small work for the continuous case and a test. More efficient builtin filters _doc_ids and _design --- Key: COUCHDB-1288 URL: https://issues.apache.org/jira/browse/COUCHDB-1288 Project: CouchDB Issue Type: Improvement Reporter: Filipe Manana Attachments: couchdb_1288_2.patch We have the _doc_ids and _design _changes filter as of CouchDB 1.1.0. While they meet the expectations of applications/users, they're far from efficient for large databases. Basically the implementation folds the entire seq btree and then filters values by the document's ID, causing too much IO and busting caches. This makes replication by doc IDs not so efficient as it could be. The proposed patch avoids this by doing direct lookups in the ID btree, for _doc_ids, and ranged fold for _design. If there are no objections, I would apply to branch 1.2.x besides -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1287) Inbox Database (write-only mode)
[
https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107666#comment-13107666
]
Benoit Chesneau commented on COUCHDB-1287:
--
@kowsic that's another topic. But indeed you can use validate update function
to forbid doc insertion. You can do it by checking the user doc. Throttling
protections and such however can be added using authenticate module eventually
or any other system.
Inbox Database (write-only mode)
--
Key: COUCHDB-1287
URL: https://issues.apache.org/jira/browse/COUCHDB-1287
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Affects Versions: 2.0
Reporter: Jason Smith
Priority: Minor
Currently, we can only grant combined read+write access in the _security
object members section. A user can either do both or neither. This prevents
a very common requirement for couch apps: sending private information from
less-privileged users to more-privileged users.
There is no (reasonable) way to make an inbox where anybody may create a
doc for me, but only I may read it. An inbox database allows user-to-user, or
user-to-admin private messages. (Not only chat messages, but asynchronous
notifications--with a per-user inbox, perhaps even service requests and
responses.)
There is no reason _security.members (formerly .readers) should control write
access. validate_doc_update() functions do this better.
I propose a boolean flag, _security.members.allow_anonymous_writes. If it is
true, then CouchDB will allow document updates from non-members, giving
validate_doc_update() the final word on accepting or rejecting the update.
Requirements:
1. Everything about _security stays the same (backward-compatible)
2. If members.allow_anonymous_writes === true, then most PUT and POSTs may
proceed
3. All updates are still subject to approval by all validate_doc_update
functions, same as before.
The following unit tests cover as much of the functionality as I can think
of. (My patch is unfinished but X indicates that I have it working.)
X Set a database with validate_doc_update, members != []
X member can write
X non-member cannot read
X non-member cannot write
X non-member cannot write even with .is_ok = true
X Set inbox mode
For non-member:
X cannot update with .is_ok = false (still subject to validator)
X can create with .is_ok = true
X can update with .is_ok = true
X Can store an attachment with _attachments
X Can store attachments via direct query
X Can delete an attachment via direct query
X can delete the doc
X can create via an _update function
X can update via an _update function
* None of these should work:
X POST a temp view
X POST a view with {keys:[keys, which, exist, and some which
don't]
* POST /db/exist X-HTTP-Method-Override: GET
* POST /db/_all_docs
* POST /db/_changes
* For _show and _list:
* POST
* OPTIONS
* VARIOUS, NONSTANDARD, METHODS (in case Couch allows them later)
* These syntax/semantic errors in _security should all fail:
* .members.required_to_write = null, [missing], , 0, true, 1, false,
[false], {false:false}
* .required_to_write = false
These are the known changes to the security model. I consider these all to be
either very unlikely in practice, or worth the trade-off.
* If you write to an inbox DB, you know, for a time, a subset of its
documents (but that's the point)
* An _update function could reveal a document to the user, with or without
changing it. However, an admin must install such a misguided update function.
* You can launch timing attacks to learn information about validate_doc_update
* You might discover whether doc IDs exist in the DB or not
* You might discover a well-known open source validation function. You can
look for bugs in its source code.
* Zero or more things which Jason can't think of
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1252) A way to have views return _deleted documents
[ https://issues.apache.org/jira/browse/COUCHDB-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107698#comment-13107698 ] James Howe commented on COUCHDB-1252: - Time's up :p A way to have views return _deleted documents - Key: COUCHDB-1252 URL: https://issues.apache.org/jira/browse/COUCHDB-1252 Project: CouchDB Issue Type: New Feature Components: JavaScript View Server Affects Versions: 1.1, 1.0.3 Reporter: James Howe Given that documents can be 'soft' deleted / deleted with auditing data by updating the document to include the _deleted property, it would be incredibly useful if there were a way to access these documents in a map function. Otherwise it is very difficult to find the auditing data - even more so if the original ids are unknown. I was thinking along the lines of a view query parameter 'include_deleted', but don't really mind how this is implemented, as long as it is there. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1288) More efficient builtin filters _doc_ids and _design
[ https://issues.apache.org/jira/browse/COUCHDB-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana updated COUCHDB-1288: --- Attachment: couchdb_1288_3.patch Added patch with test case, including the case for continuous changes. More efficient builtin filters _doc_ids and _design --- Key: COUCHDB-1288 URL: https://issues.apache.org/jira/browse/COUCHDB-1288 Project: CouchDB Issue Type: Improvement Reporter: Filipe Manana Attachments: couchdb_1288_2.patch, couchdb_1288_3.patch We have the _doc_ids and _design _changes filter as of CouchDB 1.1.0. While they meet the expectations of applications/users, they're far from efficient for large databases. Basically the implementation folds the entire seq btree and then filters values by the document's ID, causing too much IO and busting caches. This makes replication by doc IDs not so efficient as it could be. The proposed patch avoids this by doing direct lookups in the ID btree, for _doc_ids, and ranged fold for _design. If there are no objections, I would apply to branch 1.2.x besides -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1288) More efficient builtin filters _doc_ids and _design
[ https://issues.apache.org/jira/browse/COUCHDB-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107757#comment-13107757 ] Bob Dionne commented on COUCHDB-1288: - Filipe, I started reviewing this and it looks good so far. There's an edge case we ran into the other day that @davisp and @kocolosk ran down. When you have `feed=continuous` and a hearbeat and a filter function that fail enough, the heartbeat timeout never triggers and no changes are sent. It's easy to reproduce, you can see how it's handled in fabric[1]. I can probably add it to this patch or open a second ticket if you prefer. Also, as an aside the `couch_changes:get_changes_timeout` is slightly awkward in the way heartbeat is handled. It appears to allow `heartbeat=true` and in that case defaults to the timeout in the config. That certainly does not agree with the documented semantics. Cheers, Bob [1] https://github.com/cloudant/fabric/commit/f9eea28e62496afcb More efficient builtin filters _doc_ids and _design --- Key: COUCHDB-1288 URL: https://issues.apache.org/jira/browse/COUCHDB-1288 Project: CouchDB Issue Type: Improvement Reporter: Filipe Manana Attachments: couchdb_1288_2.patch, couchdb_1288_3.patch We have the _doc_ids and _design _changes filter as of CouchDB 1.1.0. While they meet the expectations of applications/users, they're far from efficient for large databases. Basically the implementation folds the entire seq btree and then filters values by the document's ID, causing too much IO and busting caches. This makes replication by doc IDs not so efficient as it could be. The proposed patch avoids this by doing direct lookups in the ID btree, for _doc_ids, and ranged fold for _design. If there are no objections, I would apply to branch 1.2.x besides -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1287) Inbox Database (write-only mode)
[
https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Smith updated COUCHDB-1287:
-
Attachment:
A_0003-Allow-non-member-writes-if-_security.members.allow_a.patch
A_0002-Refactor-the-actual-read-check-out-of-the-member-che.patch
A_0001-Refactor-reader_acl-test-functions-into-a-loop.patch
Proposed implementation attached.
## Notes
It would be nice to have _security.readers, _security.writers, and maybe sugar
_security.members which implicitly populates both. A write-only DB would have
_security.readers = {}, security.writers.roles = [_anonymous]. However this
patch maintains compatibility with the 1.x codebase. (I tagged it v2.0 because
v1.3 is not an option.)
The patch is not correct. Really, couch_db:open is an inappropriate place to
assess authorization. Couch must know what the request will do before it
determines authorization. It is unsafe to evaluate permission until execution
enters the ultimate, true request handler. (Note that couch_db:check_is_admin/1
is sprinkled everywhere. Same deal.)
A more correct patch is more substantial; but substantial code changes is
itself a security risk. I opted for the simpler way: whitelist a few good
requests based on the method #httpd.path_parts. IMO, this implementation is
fail-safe. Unexpected changes or execution isn't likely to grant access. (The
couch_db:check_is_admin/1 stuff is fail-unsafe; we must remember to call it
every time we change the code.)
Inbox Database (write-only mode)
--
Key: COUCHDB-1287
URL: https://issues.apache.org/jira/browse/COUCHDB-1287
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Affects Versions: 2.0
Reporter: Jason Smith
Priority: Minor
Attachments:
A_0001-Refactor-reader_acl-test-functions-into-a-loop.patch,
A_0002-Refactor-the-actual-read-check-out-of-the-member-che.patch,
A_0003-Allow-non-member-writes-if-_security.members.allow_a.patch
Currently, we can only grant combined read+write access in the _security
object members section. A user can either do both or neither. This prevents
a very common requirement for couch apps: sending private information from
less-privileged users to more-privileged users.
There is no (reasonable) way to make an inbox where anybody may create a
doc for me, but only I may read it. An inbox database allows user-to-user, or
user-to-admin private messages. (Not only chat messages, but asynchronous
notifications--with a per-user inbox, perhaps even service requests and
responses.)
There is no reason _security.members (formerly .readers) should control write
access. validate_doc_update() functions do this better.
I propose a boolean flag, _security.members.allow_anonymous_writes. If it is
true, then CouchDB will allow document updates from non-members, giving
validate_doc_update() the final word on accepting or rejecting the update.
Requirements:
1. Everything about _security stays the same (backward-compatible)
2. If members.allow_anonymous_writes === true, then most PUT and POSTs may
proceed
3. All updates are still subject to approval by all validate_doc_update
functions, same as before.
The following unit tests cover as much of the functionality as I can think
of. (My patch is unfinished but X indicates that I have it working.)
X Set a database with validate_doc_update, members != []
X member can write
X non-member cannot read
X non-member cannot write
X non-member cannot write even with .is_ok = true
X Set inbox mode
For non-member:
X cannot update with .is_ok = false (still subject to validator)
X can create with .is_ok = true
X can update with .is_ok = true
X Can store an attachment with _attachments
X Can store attachments via direct query
X Can delete an attachment via direct query
X can delete the doc
X can create via an _update function
X can update via an _update function
* None of these should work:
X POST a temp view
X POST a view with {keys:[keys, which, exist, and some which
don't]
* POST /db/exist X-HTTP-Method-Override: GET
* POST /db/_all_docs
* POST /db/_changes
* For _show and _list:
* POST
* OPTIONS
* VARIOUS, NONSTANDARD, METHODS (in case Couch allows them later)
* These syntax/semantic errors in _security should all fail:
* .members.required_to_write = null, [missing], , 0, true, 1, false,
[false], {false:false}
* .required_to_write = false
These are the known changes to the security model. I consider these all to be
either very unlikely in practice, or worth the trade-off.
* If you write to an inbox DB, you know, for a time, a subset of its
documents (but that's the point)
* An _update function could
[jira] [Commented] (COUCHDB-1288) More efficient builtin filters _doc_ids and _design
[ https://issues.apache.org/jira/browse/COUCHDB-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13108036#comment-13108036 ] Filipe Manana commented on COUCHDB-1288: Thanks Bob. If it's separate issue, unrelated to any changes from this patch, it should go into a separate patch/ticket :) More efficient builtin filters _doc_ids and _design --- Key: COUCHDB-1288 URL: https://issues.apache.org/jira/browse/COUCHDB-1288 Project: CouchDB Issue Type: Improvement Reporter: Filipe Manana Attachments: couchdb_1288_2.patch, couchdb_1288_3.patch We have the _doc_ids and _design _changes filter as of CouchDB 1.1.0. While they meet the expectations of applications/users, they're far from efficient for large databases. Basically the implementation folds the entire seq btree and then filters values by the document's ID, causing too much IO and busting caches. This makes replication by doc IDs not so efficient as it could be. The proposed patch avoids this by doing direct lookups in the ID btree, for _doc_ids, and ranged fold for _design. If there are no objections, I would apply to branch 1.2.x besides -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1289) heartbeats skipped when continuous changes feed filter function produces no results
heartbeats skipped when continuous changes feed filter function produces no results --- Key: COUCHDB-1289 URL: https://issues.apache.org/jira/browse/COUCHDB-1289 Project: CouchDB Issue Type: Bug Components: Database Core Reporter: Bob Dionne Priority: Minor if the changes feed has a filter function that produces no results, db_updated messages will still be sent and the heartbeat timeout will never be reached. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (COUCHDB-1289) heartbeats skipped when continuous changes feed filter function produces no results
[ https://issues.apache.org/jira/browse/COUCHDB-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Dionne reassigned COUCHDB-1289: --- Assignee: Bob Dionne heartbeats skipped when continuous changes feed filter function produces no results --- Key: COUCHDB-1289 URL: https://issues.apache.org/jira/browse/COUCHDB-1289 Project: CouchDB Issue Type: Bug Components: Database Core Reporter: Bob Dionne Assignee: Bob Dionne Priority: Minor if the changes feed has a filter function that produces no results, db_updated messages will still be sent and the heartbeat timeout will never be reached. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1289) heartbeats skipped when continuous changes feed filter function produces no results
[ https://issues.apache.org/jira/browse/COUCHDB-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13108065#comment-13108065 ] Paul Joseph Davis commented on COUCHDB-1289: There are two aspects to this that need to be considered. We've fixed both of these in BigCouch but I'm not sure if we've the first one. The first one is that if you have a large range of documents (ordered by update seq) that fail to pass a filter, there will be no heartbeat sent. Basically, the changes feed thinks its making process all hunky dory but nothing is being sent, and we never checked that its taking us too long to filter all these docs. The second version of this is slightly more insidious. Basically, the timeouts we had in BigCouch were receive timeouts in two places (no db updates, and while processing in case everything is filtered). What can end up happening is that updates to the db can end up trickling in that all fail to make it through the filter function. This means that the changes loop thinks its working again but is not hitting either timeout clause to send the heartbeat. The clustered calls in BigCouch are different enough that the patches aren't exactly applicable, but reading the code, CouchDB is at least susceptible to the second version and possible the first as well. heartbeats skipped when continuous changes feed filter function produces no results --- Key: COUCHDB-1289 URL: https://issues.apache.org/jira/browse/COUCHDB-1289 Project: CouchDB Issue Type: Bug Components: Database Core Reporter: Bob Dionne Assignee: Bob Dionne Priority: Minor if the changes feed has a filter function that produces no results, db_updated messages will still be sent and the heartbeat timeout will never be reached. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1290) rewrite with variable and query option produces a badarg error
rewrite with variable and query option produces a badarg error
--
Key: COUCHDB-1290
URL: https://issues.apache.org/jira/browse/COUCHDB-1290
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.1, 1.2
Environment: Linux geminiman 3.0.0-1-amd64 #1 SMP Sat Aug 27 16:21:11
UTC 2011 x86_64 GNU/Linux
Reporter: matthew o'gorman
Priority: Minor
This bug is similar or is the old bug
https://issues.apache.org/jira/browse/COUCHDB-1074
way to expose. put in rewrites.json
[ { from : foo/:blah, to : _list/foo/foo, query : {descending:
true}}]
returns
wget http://localhost:5984/mydb/_design/mydb/_rewrite/foo/1
{error:unknown_error,reason:badarg}
wget http://localhost:5984/mydb/_design/mydb/_rewrite/foo/string
{error:unknown_error,reason:badarg}
wget http://localhost:5984/mydb/_design/mydb/_rewrite/foo/true
{error:unknown_error,reason:badarg}
it doesnt matter whats passed. removing the query from the rewrite rule and it
wont complain about badargs. tested on version 1.1 as well as trunk-r1172741
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1290) rewrite with variable and query option produces a badarg error
[
https://issues.apache.org/jira/browse/COUCHDB-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13108099#comment-13108099
]
matthew o'gorman commented on COUCHDB-1290:
---
I spoke to soon it does seem to be fixed in r1172741 will have to play with a
bit more and see why i thought otherwise.
rewrite with variable and query option produces a badarg error
--
Key: COUCHDB-1290
URL: https://issues.apache.org/jira/browse/COUCHDB-1290
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.1, 1.2
Environment: Linux geminiman 3.0.0-1-amd64 #1 SMP Sat Aug 27 16:21:11
UTC 2011 x86_64 GNU/Linux
Reporter: matthew o'gorman
Priority: Minor
This bug is similar or is the old bug
https://issues.apache.org/jira/browse/COUCHDB-1074
way to expose. put in rewrites.json
[ { from : foo/:blah, to : _list/foo/foo, query : {descending:
true}}]
returns
wget http://localhost:5984/mydb/_design/mydb/_rewrite/foo/1
{error:unknown_error,reason:badarg}
wget http://localhost:5984/mydb/_design/mydb/_rewrite/foo/string
{error:unknown_error,reason:badarg}
wget http://localhost:5984/mydb/_design/mydb/_rewrite/foo/true
{error:unknown_error,reason:badarg}
it doesnt matter whats passed. removing the query from the rewrite rule and
it wont complain about badargs. tested on version 1.1 as well as
trunk-r1172741
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-1290) rewrite with variable and query option produces a badarg error
[
https://issues.apache.org/jira/browse/COUCHDB-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
matthew o'gorman closed COUCHDB-1290.
-
Resolution: Not A Problem
it seems to have been pebkac on my end you need around bools
rewrite with variable and query option produces a badarg error
--
Key: COUCHDB-1290
URL: https://issues.apache.org/jira/browse/COUCHDB-1290
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.1, 1.2
Environment: Linux geminiman 3.0.0-1-amd64 #1 SMP Sat Aug 27 16:21:11
UTC 2011 x86_64 GNU/Linux
Reporter: matthew o'gorman
Priority: Minor
This bug is similar or is the old bug
https://issues.apache.org/jira/browse/COUCHDB-1074
way to expose. put in rewrites.json
[ { from : foo/:blah, to : _list/foo/foo, query : {descending:
true}}]
returns
wget http://localhost:5984/mydb/_design/mydb/_rewrite/foo/1
{error:unknown_error,reason:badarg}
wget http://localhost:5984/mydb/_design/mydb/_rewrite/foo/string
{error:unknown_error,reason:badarg}
wget http://localhost:5984/mydb/_design/mydb/_rewrite/foo/true
{error:unknown_error,reason:badarg}
it doesnt matter whats passed. removing the query from the rewrite rule and
it wont complain about badargs. tested on version 1.1 as well as
trunk-r1172741
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1291) New couch_mrview engine uses {val,_} in {row,_} instead of expected {value,_}
[
https://issues.apache.org/jira/browse/COUCHDB-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Bonhage updated COUCHDB-1291:
-
Attachment: 0001-mrview_row_format_consistency.patch
s/{val,/{value,/g
New couch_mrview engine uses {val,_} in {row,_} instead of expected {value,_}
-
Key: COUCHDB-1291
URL: https://issues.apache.org/jira/browse/COUCHDB-1291
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 2.0
Environment: Mac OS X 10.7.1, Erlang R14B04
Reporter: Christopher Bonhage
Priority: Trivial
Fix For: 2.0
Attachments: 0001-mrview_row_format_consistency.patch
Original Estimate: 0h
Remaining Estimate: 0h
Internally, it appears as though the new reference implementation for views
uses the row convention of {row, [{id,_}, {key,_}, {val,_}, {doc,_}]}, which
is inconsistent with output convention of {id:_, key:_, value: _,
doc: _}. For the sake of sanity, and since couch_mrview is to be a
reference implementation, I propose that {val,_} be changed to {value,_}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1291) New couch_mrview engine uses {val,_} in {row,_} instead of expected {value,_}
New couch_mrview engine uses {val,_} in {row,_} instead of expected {value,_}
-
Key: COUCHDB-1291
URL: https://issues.apache.org/jira/browse/COUCHDB-1291
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 2.0
Environment: Mac OS X 10.7.1, Erlang R14B04
Reporter: Christopher Bonhage
Priority: Trivial
Fix For: 2.0
Attachments: 0001-mrview_row_format_consistency.patch
Internally, it appears as though the new reference implementation for views
uses the row convention of {row, [{id,_}, {key,_}, {val,_}, {doc,_}]}, which is
inconsistent with output convention of {id:_, key:_, value: _, doc: _}.
For the sake of sanity, and since couch_mrview is to be a reference
implementation, I propose that {val,_} be changed to {value,_}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1292) validate_doc_update: function(n,o,u){}
validate_doc_update: function(n,o,u){}
Key: COUCHDB-1292
URL: https://issues.apache.org/jira/browse/COUCHDB-1292
Project: CouchDB
Issue Type: Improvement
Components: Database Core
Affects Versions: 1.2
Environment: linux
Reporter: gert cuykens
Priority: Trivial
Assign a function instead of a string to make validation handler consistent
with the update handlers
consistent = updates: { hello: function(d,r) {} }
consistent = validate_doc_update: function(n,o,u){}
inconsistent = validate_doc_update: function(n,o,u){}
http://wiki.apache.org/couchdb/Document_Update_Handlers
http://wiki.apache.org/couchdb/Document_Update_Validation
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1292) validate_doc_update: function(n,o,u){}
[
https://issues.apache.org/jira/browse/COUCHDB-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13108323#comment-13108323
]
gert cuykens commented on COUCHDB-1292:
---
Guess I was wrong. Can somebody edit the wiki pleas. And use
function(d,r){...} instead of a note: The functions should be double-quoted
JSON strings.
validate_doc_update: function(n,o,u){}
Key: COUCHDB-1292
URL: https://issues.apache.org/jira/browse/COUCHDB-1292
Project: CouchDB
Issue Type: Improvement
Components: Database Core
Affects Versions: 1.2
Environment: linux
Reporter: gert cuykens
Priority: Trivial
Labels: couchdb
Original Estimate: 24h
Remaining Estimate: 24h
Assign a function instead of a string to make validation handler consistent
with the update handlers
consistent = updates: { hello: function(d,r) {} }
consistent = validate_doc_update: function(n,o,u){}
inconsistent = validate_doc_update: function(n,o,u){}
http://wiki.apache.org/couchdb/Document_Update_Handlers
http://wiki.apache.org/couchdb/Document_Update_Validation
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1292) validate_doc_update: function(n,o,u){}
[
https://issues.apache.org/jira/browse/COUCHDB-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski resolved COUCHDB-1292.
-
Resolution: Not A Problem
Hi Gert, the wiki is user-editable, no need for a commit bit.
validate_doc_update: function(n,o,u){}
Key: COUCHDB-1292
URL: https://issues.apache.org/jira/browse/COUCHDB-1292
Project: CouchDB
Issue Type: Improvement
Components: Database Core
Affects Versions: 1.2
Environment: linux
Reporter: gert cuykens
Priority: Trivial
Labels: couchdb
Original Estimate: 24h
Remaining Estimate: 24h
Assign a function instead of a string to make validation handler consistent
with the update handlers
consistent = updates: { hello: function(d,r) {} }
consistent = validate_doc_update: function(n,o,u){}
inconsistent = validate_doc_update: function(n,o,u){}
http://wiki.apache.org/couchdb/Document_Update_Handlers
http://wiki.apache.org/couchdb/Document_Update_Validation
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
