couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 7zark7 <7za...@gmail.com>
Subject Re: Rewrite /user/bob to user:bob
Date Sun, 21 Aug 2011 16:23:43 GMT
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 <sim.leblanc@gmail.com> 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 <rnewson@apache.org> 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 <mark@boutiquing.com> 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 <sim.leblanc@gmail.com
>>>> 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…
>>>> 
>>> 
> 

Mime
View raw message