couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hahn <m...@boutiquing.com>
Subject Re: Rewrite /user/bob to user:bob
Date Fri, 19 Aug 2011 21:09:22 GMT
FWIW, I don't allow direct access to couch from users so I don't have your
need for such URLs.  I found that my security needs were impossible to
implement directly in couch.  All user access to my system is through node.
 As a fringe benefit I found node to be extremely flexible, much more so
than direct access to couch.

On Fri, 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message