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
https://github.com/natevw/Glob/blob/master/rewrites.json and it's in use at
http://n.exts.ch 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
(http://wiki.apache.org/couchdb/Document_Update_Handlers) 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 capabilities
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?
hth,
-natevw
