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… >>> >>
