couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Leblanc <>
Subject Re: Rewrite /user/bob to user:bob
Date Fri, 19 Aug 2011 19:20:44 GMT
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

My thinking is oriented by the fact that I would prefer to have nice urls like
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 <> 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 <> 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 <
>>> 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…

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