2010-07-06 2 views
5

J'ai une page d'inscription qui demande à l'utilisateur d'entrer un nom d'utilisateur et une adresse e-mail.Comment vérifier la disponibilité et réserver des noms d'utilisateur dans CouchDB

Je dois vérifier pour voir si le nom d'utilisateur + email est disponible. Comment faire cela avec une seule requête HTTP?

BTW, le nom d'utilisateur est utilisé comme docID. Ce que je fais en ce moment vérifie si le docID existe, puis utilise une vue pour vérifier la disponibilité de l'adresse email, mais c'est 2 requêtes HTTP. J'ai pensé à utiliser une vue pour émettre [nom d'utilisateur, email] comme clé et interroger la vue avec une "clé" param = [nom d'utilisateur, email]. Mais cela ne fonctionnera pas si le nom d'utilisateur et le courriel appartiennent à différents utilisateurs existants.

+0

duplication possible de [Contraintes uniques dans couchdb] (http://stackoverflow.com/questions/1541239/unique-constraints-in-couchdb) – Flimzy

Répondre

1

Jason. La solution de Sam est très utile mais, comme vous le dites, elle n'est peut-être pas parfaite pour vous. Je peux penser à deux autres options. Imaginez un instant que vous êtes de retour dans SQL. Quelle est la clé primaire d'un utilisateur? Ce n'est ni le nom d'utilisateur ni l'email mais les deux colonnes. Idem pour CouchDB.

Donc, à absolument garantir l'unicité, la réponse est simple: il doit être le doc _id. Par exemple, pour l'utilisateur "jason" avec le courrier électronique "[email protected]", POST ce doc:

{ "_id": "jason:[email protected]", 
    "other stuff": "blah blah blah" 
} 

C'est atomique, transactionnel, la création d'utilisateurs. Il pourrait:

  • Succeed, maintenant que vous avez votre nouveau document utilisateur
  • Fail parce que id existe déjà et vous (intentionnellement) a oublié la propriété _rev. Super, ce combo utilisateur/email est déjà pris!

Bien sûr, simplement vérifier si le nom est disponible, vous pouvez GET /db/jason:[email protected]. (Vous pouvez préfixer l'ID comme le fait la base de données _users, comme users:jason:[email protected] — c'est à vous de décider.) Ensuite, vous pouvez POST revenir plus tard. Il y a une chance que cela soit pris entre temps, mais c'est normal dans tous les formulaires "vérifier d'abord, réserver plus tard" qui sont assez courants sur le web maintenant.

La deuxième idée est plus juste de réfléchir soigneusement à votre situation. Vous avez dit que deux utilisateurs peuvent avoir le même nom d'utilisateur: et. Cela semble étrange. Peut-être que j'ai mal lu. Voici quelques choses à penser:

  • Presque personne actions un compte e-mail avec quelqu'un d'autre. Pourquoi ne pas en faire le nom de connexion actuel? C'est assez bon pour Facebook. Alors le "nom d'utilisateur" peut juste être le surnom d'un utilisateur ou manipuler dans le système, juste une propriété dans le document d'utilisateur.
  • Deux requêtes HTTP peuvent ne pas être si mauvaises.Je pense que de cette façon:
    • Si ceci est une architecture 3-tier (serveur web dédié, backend CouchDB), puis deux requêtes HTTP est pas grand
    • Si c'est un 2-tier ou hybride (où les navigateurs tapent directement sur couchdb), puis pensez fortement à utiliser CouchDB pour l'authentification, décrite dans le CouchDB book. CouchDB peut gérer les connexions pour vous, avec un formulaire ou AJAX. Ce n'est pas parfait pour toutes les situations, mais vous obtenez un excellent rapport qualité-prix.
+0

P.S. Possédez-vous vraiment [email protected]? Heureux bâtard! : p – JasonSmith

+0

Mes excuses pour répondre à une question si ancienne, mais je suis confronté à la même question. "Pourquoi ne pas en faire le nom de connexion réel? C'est assez bon pour Facebook." 1) Facebook ne fait pas ça. Facebook utilise des ID numériques uniques, qui ont des adresses électroniques, des noms, des surnoms * et * des noms d'utilisateur qui leur sont associés. 2) Les adresses e-mail changent souvent. – Flimzy

0

vous pouvez passer votre URL avec

http://localhost:5984/yourdatabase/_design/viewname/_view/viewid?key=["username","password"] 

qui renverra les données si le même nom d'utilisateur et mot de passe existent dans votre document.

Questions connexes