nœud unique CouchDB, Doc multi Transaction

Question

Si l'on suppose qu'il existe une fonction validate_doc_update, dans le document de conception, défini comme:

{ 
    "_id": "_design/ddoc", 
    "_rev": "12-133b5dad579f872884a9ccd6d4be5ee9", 
    "language": "javascript", 
    "validate_doc_update": "function(newDoc, oldDoc, userCtx) { 
     if (oldDoc._rev != newDoc._rev) { throw('FAILED') } 
    }" 
} 

Si nous effectuons une mise à jour en vrac (_bulk_docs); est-il transnational pour plus d'un document?

Note: J'ai trouvé this réponse et j'ai lu les documents et j'ai exécuté un code de test. Et il semble que ce soit un moyen idéal d'effectuer des transactions sur CouchDB! Mais puisque je ne l'ai pas vu ailleurs (et je me demandais pourquoi?); voulait s'assurer que, ce n'est pas une erreur.

Answer 1

CouchDB dev ici.

Ceci est pas transactionnel, et c'est par conception, même sur un seul nœud.

La raison en est que nous ne voulons pas que les API de CouchDB se brisent lorsque vous passez d'une installation à un seul nœud à une installation en cluster.

Dans un cluster, il est beaucoup plus difficile de garantir une transaction multi-doc, donc CouchDB ne l'essaie même pas.

Answer 2

Je voudrais ajouter que vous pouvez souvent stocker la transaction complète dans un seul document, puis prendre des vues à votre avantage pour montrer les résultats. Par exemple, pour stocker un transfert d'espèces, au lieu de stocker deux documents décrivant le dépôt et le retrait, stockez les deux dans un document de type «transfert», puis créez une vue en retournant les soldes de chaque compte.

Ou pour prendre l'exemple dans le question you referred to: Si vous voulez vous assurer qu'il n'y a qu'un seul roi dans la base de données à la fois, utilisez simplement un document avec le _id = 'king' et y stocker toutes les informations sur le roi . Si le roi change, il suffit de changer les données réelles du roi dans ce document. Vous obtiendriez un conflit si deux clients essayaient de changer le roi en même temps. Btw cela fonctionnerait également très bien si vous utilisiez plusieurs nœuds ou plusieurs réplicas, par exemple pour des clients hors ligne via PouchDB. Vous devrez éventuellement envisager de résoudre les conflits, mais à la conception, vous ne rencontrerez jamais deux rois. Donc, selon vos besoins, modélisez vos documents en conséquence. Si vous avez besoin de transactions, stockez chaque transaction dans un seul document.