[jira] Created: (COUCHDB-688) Allow status codes other than 401 and 403 thrown from validate_update_doc function
Allow status codes other than 401 and 403 thrown from validate_update_doc
function
--
Key: COUCHDB-688
URL: https://issues.apache.org/jira/browse/COUCHDB-688
Project: CouchDB
Issue Type: Improvement
Reporter: Isaac Z. Schlueter
Priority: Minor
It would be good to be able to send a response other than 401 or 403 from the
validate_update_doc function. Occasionally, a web application built on top of
couch may have more subtle semantics than those afforded by these two options.
For instance, a user may attempt to post a version into a package management
registry web-app built on couch. While "unicorn" is a perfectly understandable
json string by couchdb, it's not a parseable or valid semver version. I'd like
in that case to return a 400 "bad request", because the client sent a request
body that this resource could not understand.
Additionally, there may be cases where a "conflict" is somewhat more broadly
understood than couch's _rev matching, and a 409 might be appropriate.
Proposal: Allow validate_update_doc to specify an HTTP error code like so:
throw { code : 403, message : "Unauthorized access to foo" }
throw { code : 410 } // generic message for this status code
etc.
in addition to the current:
throw { unauthorized : "reason" }
throw { forbidden : "reason" }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Content-Type Negotiation/Programmatic URL rewriting
On 10 Mar 2010, at 21:07, J Chris Anderson wrote:
>
> On Mar 10, 2010, at 7:47 PM, Robert Newson wrote:
>
>> All,
>>
>> I want to retrieve the JSON document or a specific binary attachment
>> of it from the same URL, conditional on the Accept header. That is,
>> "/db/doc" is either JSON metadata or a binary stream, depending on
>> content-type negotiation. The below rewrite enhancement would achieve
>> it, I think, but perhaps there's a cleaner way? Right now, I'm adding
>> another Erlang module to achieve this but I would really like to do it
>> entirely from a design document.
>>
>> I'm thinking of writing a new kind of rewrite handler. I have a case
>> where it would be very useful to rewrite a URL based on the contents
>> of a request header. That is, the presence of a particular header will
>> alter the path, but not otherwise;
>>
>> {
>> "_id":"_design/foo",
>> "rewrites": {
>> "bar": {
>> "function":"function(req){ if (req.headers["Accept"] == blah) {
>> return req.path + "extra";} return req.path"
>>
>> that is, the rewrite handler would get a full request object and
>> return the rewritten path, and could use anything from the request to
>> do so.
>>
>
> we originally decided against an executable rewrite handler for reasons of
> performance.
One could argue that optional executable rewrites are okay. Especially when
written as
Erlang functions.
> is there a way to add to the pattern matching api to achieve this?
"from": {
"path":"/db/:doc",
"headers":{"Accept":"application/octet-stream"}
},
"to":"/db/doc/attachment"
"from": {
"path":"/db/:doc",
"headers":{"Accept":"application/json"}
},
"to":"/db/doc"
Could do the trick, but I don't want to be the one implementing that :)
Cheers
Jan
--
Re: Content-Type Negotiation/Programmatic URL rewriting
On Mar 10, 2010, at 7:47 PM, Robert Newson wrote:
> All,
>
> I want to retrieve the JSON document or a specific binary attachment
> of it from the same URL, conditional on the Accept header. That is,
> "/db/doc" is either JSON metadata or a binary stream, depending on
> content-type negotiation. The below rewrite enhancement would achieve
> it, I think, but perhaps there's a cleaner way? Right now, I'm adding
> another Erlang module to achieve this but I would really like to do it
> entirely from a design document.
>
> I'm thinking of writing a new kind of rewrite handler. I have a case
> where it would be very useful to rewrite a URL based on the contents
> of a request header. That is, the presence of a particular header will
> alter the path, but not otherwise;
>
> {
> "_id":"_design/foo",
> "rewrites": {
>"bar": {
> "function":"function(req){ if (req.headers["Accept"] == blah) {
> return req.path + "extra";} return req.path"
>
> that is, the rewrite handler would get a full request object and
> return the rewritten path, and could use anything from the request to
> do so.
>
we originally decided against an executable rewrite handler for reasons of
performance.
is there a way to add to the pattern matching api to achieve this?
Chris
> Thoughts?
> B.
Content-Type Negotiation/Programmatic URL rewriting
All,
I want to retrieve the JSON document or a specific binary attachment
of it from the same URL, conditional on the Accept header. That is,
"/db/doc" is either JSON metadata or a binary stream, depending on
content-type negotiation. The below rewrite enhancement would achieve
it, I think, but perhaps there's a cleaner way? Right now, I'm adding
another Erlang module to achieve this but I would really like to do it
entirely from a design document.
I'm thinking of writing a new kind of rewrite handler. I have a case
where it would be very useful to rewrite a URL based on the contents
of a request header. That is, the presence of a particular header will
alter the path, but not otherwise;
{
"_id":"_design/foo",
"rewrites": {
"bar": {
"function":"function(req){ if (req.headers["Accept"] == blah) {
return req.path + "extra";} return req.path"
that is, the rewrite handler would get a full request object and
return the rewritten path, and could use anything from the request to
do so.
Thoughts?
B.
[jira] Created: (COUCHDB-687) Add md5 hash to _attachments properties for documents
Add md5 hash to _attachments properties for documents
-
Key: COUCHDB-687
URL: https://issues.apache.org/jira/browse/COUCHDB-687
Project: CouchDB
Issue Type: Improvement
Environment: CouchDB
Reporter: mikeal
The current attachment information looks like this:
GET /dbname/docid
"_attachments": {
"jquery-1.4.1.min.js": {
"content_type": "text/javascript"
"revpos": 138
"length": 70844
"stub": true
}
}
If a client wanted to sync local files as attachments with a document it would
not currently be able to do so without keeping a local store of the revpos. If
this information included an md5 hash of the attachment clients could compare
it against a hash of the local file to see if they match.
-Mikeal
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-686) Improve ordering of replication
[ https://issues.apache.org/jira/browse/COUCHDB-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843665#action_12843665 ] Chris Anderson commented on COUCHDB-686: Randall's suggestion seems the most appropriate here. However, I'd caution against this using such a feature. For the same reasons we don't support multi-document transactions on a single node (b/c they can't be sanely supported on a cluster), supporting ordering guarantees is dangerous. They are essentially a form of multi-document state. Since is is very clear that they can't be supported in a replication mesh with more than 2 peers, I don't think they are so dangerous as that we shouldn't provide Randall's knob. But we should be clear to the people who choose to architect around it, that what they are doing will be limited to the maximum throughput of a single disk. > Improve ordering of replication > --- > > Key: COUCHDB-686 > URL: https://issues.apache.org/jira/browse/COUCHDB-686 > Project: CouchDB > Issue Type: Improvement > Components: Replication >Affects Versions: 0.10.1 >Reporter: Dirkjan Ochtman >Priority: Minor > Fix For: 0.12 > > > Currently, (continuous) replication almost preserves the ordering of the > updates. It would be nice if this could be fixed so that the order of > outgoing updates fully corresponds to the order inside the source database. > While this may fall down in some clustering situations, it's a great > guarantee to provide in many smaller situations involving an ordered stream > of documents/updates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-686) Improve ordering of replication
[ https://issues.apache.org/jira/browse/COUCHDB-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843602#action_12843602 ] Adam Kocoloski commented on COUCHDB-686: Replication always uses the changes feed if it's available. The rationale for not using include_docs=true is that for some replications the target already has a large fraction of the updates. In those cases it can be wasteful to transfer the full document. However, that's probably the exception to the rule. A nice optimization might be for the replicator to track the fraction of source updates which are present on the target, and if that fraction drops too low, just start including docs directly in the changes feed. Or at least, to stop checking _missing_revs on the target. But that's tangential to this discussion. > Improve ordering of replication > --- > > Key: COUCHDB-686 > URL: https://issues.apache.org/jira/browse/COUCHDB-686 > Project: CouchDB > Issue Type: Improvement > Components: Replication >Affects Versions: 0.10.1 >Reporter: Dirkjan Ochtman >Priority: Minor > Fix For: 0.12 > > > Currently, (continuous) replication almost preserves the ordering of the > updates. It would be nice if this could be fixed so that the order of > outgoing updates fully corresponds to the order inside the source database. > While this may fall down in some clustering situations, it's a great > guarantee to provide in many smaller situations involving an ordered stream > of documents/updates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-686) Improve ordering of replication
[ https://issues.apache.org/jira/browse/COUCHDB-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843502#action_12843502 ] Dirkjan Ochtman commented on COUCHDB-686: - Hmm, so I read somewhere that continuous replication just uses the changes feed off of the source db. If that's true, maybe we can restrict this further to continuous replication only, and have it use the changes feed with include_docs=true? That should make it even easier, and faster to do this. > Improve ordering of replication > --- > > Key: COUCHDB-686 > URL: https://issues.apache.org/jira/browse/COUCHDB-686 > Project: CouchDB > Issue Type: Improvement > Components: Replication >Affects Versions: 0.10.1 >Reporter: Dirkjan Ochtman >Priority: Minor > Fix For: 0.12 > > > Currently, (continuous) replication almost preserves the ordering of the > updates. It would be nice if this could be fixed so that the order of > outgoing updates fully corresponds to the order inside the source database. > While this may fall down in some clustering situations, it's a great > guarantee to provide in many smaller situations involving an ordered stream > of documents/updates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
