Comment garantissez-vous l'unicité d'un champ dans un document CouchDB?

Question

Juste ce qu'il dit sur l'étain. J'ai un tas de (par exemple) documents de membre, je veux que chaque utilisateur puisse placer le champ de courrier électronique sur son document à ce qu'il veut, exemple un email qui existe sur un autre document. Si je fais juste une vérification-insertion, je suis vulnérable à une condition de concurrence. Existe-t-il un idiome pour "verrouiller" ou insérer-puis-vérifier?

Answer 1

Le seul moyen sûr est de créer un document avec la valeur unique en tant que doc ID.

Answer 2

Comme les autres notes de réponse, le seul champ garanti d'être unique dans CouchDB est _id.

Vous pourriez emprunter un tour du réplicateur ici. Afin de faire avancer rapidement une deuxième réplication entre les deux mêmes hôtes, il écrit un document de point de contrôle qui enregistre la dernière séquence de mise à jour atteinte. Mais comment trouve-t-il le document de point de contrôle à l'avenir? Ainsi;

"_id": md5 (source.host + source.port + target.host + target.port)

Un schéma général peut être extrait où vos champs uniques font partie de l'identifiant lui-même. Leur exécution via md5 garantit un identifiant de longueur fixe.

Dans votre cas, vous pouvez simplement utiliser votre adresse e-mail comme ID.

La modification de l'un de ces champs est un processus en deux étapes, mais qui conserve la propriété d'unicité.

1. Copiez le document à son nouveau id (http://wiki.apache.org/couchdb/HTTP_Document_API#COPY)
2. En cas de succès, supprimez l'ancien (http://wiki.apache.org/CouchDB/HTTP_Document_API # SUPPRIMER)

un accident entre les étapes 1 et 2 laissera l'ancien document, il place, de sorte que vous voudrez peut-être ajouter une référence à l'ancien document dans le nouveau document. Vous pouvez ensuite créer une vue de ces références et effectuer un balayage de nettoyage périodiquement. Cela dit, CouchDB ne prend délibérément en charge qu'un seul champ unique, contrairement à un SGBDR typique qui peut prendre en charge des contraintes relationnelles élaborées, afin qu'une solution puisse évoluer proprement dans un cluster (c.f, BigCouch). Dans votre cas, où l'adresse e-mail doit être unique, une grande partie de ce que j'ai dit devrait fonctionner (les adresses e-mail ne changent pas si souvent), mais évidemment, cela nage en amont dans une certaine mesure.

HTH, B.