incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Vander Wilt <>
Subject Re: Rewrite inside of a path segment
Date Wed, 19 Sep 2012 20:24:41 GMT

On Sep 18, 2012, at 1:16 AM, Robin Berjon wrote:

> The problem is that I need a rewrite that invariably accepts parameters that don't fall
at the / boundary. Typically:
> {
>    from:   "/blog/*"
> ,   to:     "../../blog.*"
> ,   method: "DELETE"
> }
> And that doesn't work. It just invariably encodes the * or :id, or whatnot. Have I missed
something? I of course could simply expose another ID for DELETE or ugly IDs everywhere, but
that completely defeats the point of having rewrites in the first place.

You have not missed anything. The problem is that you're wanting a rewrite doesn't fall on
/ boundaries, and the simplistic rewrite handler does not support this. I wish that rewrites
were implemented in JavaScript instead of this one-off metalanguage, but my dreams aren't
much practical value to you right now ;-)

What I did for the only situation where I've tried to use rewrites in earnest (a blog too,
actually) was rely mostly on list functions to show documents by a different key ("path" or
"slug" or something) rather than their ID. You can see my hacky rewrites and browse to the
broader context via and it's in use
at if you're interested.

Unfortunately, I don't think there's much you could do in the case of a DELETE like this where
you can't use view tricks to do without the actual document _id. I'd generally recommend using
the _id field *only* as a unique object identifier  — I do often prefix my doc._ids but
only as a debugging/troubleshooting aid for my human eyes; any typing information should be
encoded elsewhere in the document so code can just treat it as an opaque string.

So I think your options would be to either:
- use something like nginx or node.js to handle rewrites
- [haven't tested] hack up a POST update handler (
that takes in the _rev and _id and attempts to overwrite the exisiting document with one that
has "_delete":true
- restructure your app/document design so that it fits within CouchDB's very limited _rewrite

As it seems end-users won't tend to linger on a deletion URL anyway, I'm wondering if the
last option wouldn't be best — who cares if the request happens to have full "blog." prefixed
identifier if that's the _id anyway?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message