Hi Simon, We went through a similar issue with rewriting due to our need to use doc ids that contained and/or could be requested via paths with one or more slashes.
We finally found the simplest solution was a proxy in front of couch (netscaler or nginx, etc) which did our rewriting, which did / escaping to %2F and other rearranging. Hope thus helps. On Aug 19, 2011, at 12:20 PM, Simon Leblanc <[email protected]> wrote: > Mark, I understand what you mean and I agree. I also thought about that. > Changing a user name or deleting a user is complicated. There is a risk of > leaving broken links all around the place, or worse, pointing to the wrong > person. I'm still not sure how I want to deal with that > > My thinking is oriented by the fact that I would prefer to have nice urls > like http://foo.com/user/bob. > Then the only information I have to retrieve the user document is "user/bob". > Why not make it the docid then? > > Le 19 août 2011 à 15:03, Mark Hahn a écrit : > >>> Curiously, I generally think the opposite. >> >> I should add that I also like to have all fields be changeable by the user. >> If I used email as the user key and put it in as the doc id, then it would >> be hard to impossible to change the email address later. I made this >> mistake once. >> >>> If you do so, then couchdb will largely prevent (and at least detect) >> conflicts for you. >> >> What good does it do to have the db detect your problems, other that maybe >> as a debugging aid? I would think that making a fundamental decision about >> your schema for debugging purposes would be short-sighted. It was ok to do >> this in SQL because the checking was external to the schema design, but here >> it affects the architecture. >> >> On Fri, Aug 19, 2011 at 1:04 AM, Robert Newson <[email protected]> wrote: >> >>> Curiously, I generally think the opposite. If your application has >>> properties that must be unique, or if there are non-commutative >>> operations on your documents, it's better to to use that knowledge to >>> form your id (a typical approach being to cons all the values together >>> and take the md5 and sha1 of the result). If you do so, then couchdb >>> will largely prevent (and at least detect) conflicts for you. If none >>> of your documents can possibly conflict with any other then a UUID is >>> perfectly justified. >>> >>> B. >>> >>> On 19 August 2011 01:18, Mark Hahn <[email protected]> wrote: >>>> I personally think using anything other than UUIDs for doc ids is a >>> mistake. >>>> I have found times when I want to change the architecture and having >>> fixed >>>> doc ids made it impossible. >>>> >>>> On Thu, Aug 18, 2011 at 11:47 AM, Simon Leblanc <[email protected] >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I'm trying to write a couchapp with multiple users. Two users can't have >>>>> the same name, since I want to access user bob's profile through >>> /user/bob. >>>>> Similarly, I store other documents (let's call them stuffs) with unique >>> ids >>>>> that I would like to access through /stuff/somestuff. >>>>> A user can have the same name as a stuff, and vice versa. That's why I >>>>> can't use bob or somestuff as _id (otherwise I couldn't have a stuff >>> named >>>>> bob or a user named somestuff). >>>>> >>>>> I see 3 options: >>>>> use different databases for users and stuffs, but that means two design >>>>> documents and it kind of defeats the purpose of couchapps >>>>> use uuids and deal with names in a custom manner. Sounds difficult. I >>> would >>>>> really prefer the third option: >>>>> use a naming convention for ids, like user:bob and stuff:somestuff. >>>>> >>>>> My favorite choice so far is the third option. The colon can be replaced >>> by >>>>> any character, like dash, underscore, comma, @ or even nothing if this >>> can >>>>> help. The prefix can also be a postfix. >>>>> I initially tried with a forward slash which was perfect until I >>> realized >>>>> it was not really supported and it caused problems with update functions >>>>> (see COUCHDB-1229). >>>>> >>>>> Is it possible to rewrite /user/bob to, for instance, >>>>> /_show/profile/user:bob or /_show/profile/user_bob ? >>>>> I tried {"from": "user/*", "to": "_show/profile/user:bob"} and variants >>>>> with no success. >>>>> >>>>> If it is not possible, what would be the best alternative? >>>>> >>>>> Thanks a lot for your help, >>>>> >>>>> Simon >>>>> >>>>> >>>>> PS: For the sake of learning, I'm trying to write a pure couchapp >>> without >>>>> client-side javascript… >>>> >>> >
