Pas de. CouchDB utilise un "accès concurrentiel optimiste" modèle. En termes simples, cela signifie que vous envoyer une version de document avec la mise à jour, et CouchDB rejette le changement si l'actuelle version du document ne correspond pas à ce que vous avez envoyés.
C'est trompeusement simple, vraiment. Vous pouvez recadrer beaucoup de la transaction normale en fonction des scénarios pour CouchDB. Vous avez besoin de faire en sorte de jetez votre SGBDR domaine de connaissances lors de l'apprentissage de CouchDB. Il est utile d'aborder les problèmes à partir d'un niveau plus élevé, plutôt que d'essayer de moule Canapé pour un SQL.
Garder la trace de l'inventaire
Le problème que vous avez décrit est principalement une question d'inventaire. Si vous avez un document décrivant un élément, et il comprend un champ "quantité disponible", vous pouvez gérer des problèmes de concurrence, comme ceci:
- Récupérer le document, de prendre note de l'
_rev bien que CouchDB envoie le long de
- Décrémenter le champ de la quantité, si elle est supérieure à zéro
- Envoyer le document mis à jour en arrière, à l'aide de l'
_rev de la propriété
- Si l'
_rev correspond au numéro actuellement stocké être fait!
- Si il y a un conflit (lorsqu'
_rev ne correspond pas), récupérer la dernière version du document
Dans ce cas, il y a deux scénarios de panne à penser. Si la plus récente version du document a une quantité de 0, vous la gérer comme vous le feriez dans un SGBDR et de signaler à l'utilisateur qu'ils ne peuvent pas acheter ce qu'ils voulaient acheter. Si la plus récente version du document a une quantité supérieure à 0, il vous suffit de répéter l'opération avec les données mises à jour, et recommencer au début. Cela vous oblige à faire un peu plus de travail que d'un SGBDR serait, et pourrait obtenir un peu ennuyeux si il y a de fréquentes, des mises à jour contradictoires.
Maintenant, la réponse que je viens de faire suppose que vous allez faire les choses dans CouchDB de la même manière que vous le feriez dans un SGBDR. J'ai peut-être l'approche de ce problème un peu différemment:
J'aimerais commencer avec un "produit de référence" document qui comprend tous les descripteurs de données (nom, photo, description, prix, etc). Ensuite, j'ai ajouter un "inventaire ticket" document pour chaque instance spécifique, avec des champs pour l' product_key et claimed_by. Si vous vendez un modèle de marteau, et 20 d'entre eux pour vendre, vous pourriez avoir des documents avec les touches hammer-1, hammer-2, etc, pour représenter chaque marteau.
Alors, j'aimerais créer une vue qui me donne une liste de marteaux, avec une fonction de réduction qui me permet de voir un "total". Ces sont complètement à côté de la manchette, mais devrait vous donner une idée de ce que d'un point de vue travail.
Carte
function(doc)
{
if (doc.type == 'inventory_ticket' && doc.claimed_by == null ) {
emit(doc.product_key, { 'inventory_ticket' :doc.id, '_rev' : doc._rev });
}
}
Cela me donne une liste de "billets", par la clé de produit. Je pourrais prendre un groupe de ces quand quelqu'un veut acheter un marteau, puis itérer à travers l'envoi de mises à jour (à l'aide de l' id et _rev) jusqu'à ce que j'ai réussi à réclamer un (auparavant demandé des billets résultera en une erreur de mise à jour).
Réduire
function (keys, values, combine) {
return values.length;
}
Cette fonction de réduction retourne simplement le nombre total de non réclamés inventory_ticket articles, de sorte que vous pouvez dire combien de "marteaux" sont disponibles à l'achat.
Mises en garde
Cette solution représente environ 3,5 minutes du total de la pensée pour le problème que vous avez présenté. Il peut y avoir de meilleures façons de le faire! Cela dit, il n'réduire considérablement les mises à jour conflictuelles, et les coupes vers le bas sur la nécessité de répondre à un conflit avec une nouvelle mise à jour. En vertu de ce modèle, vous n'aurez pas à plusieurs utilisateurs de tenter de modifier les données dans le primaire, l'entrée d'un produit. Au pire, vous aurez de multiples utilisateurs tentant de réclamer un billet unique, et si vous avez saisi plusieurs de ceux de votre point de vue, il vous suffit de passer à côté du billet et essayez de nouveau.
