それはすることが可能であるputかbulkDocsのCouchDB / pouchdbへとIEでリビジョンを受賞し、複製と同じ動作を得る_conflicts代わりに409応答？
基本的にconflict、次のコードではこのケースを避けたいと思います。
const docs = Object
.keys(pendingSet)
.map(id => toDoc(deepClone(pendingSet[id]), { id, rev: this.revCache.get(id) }))
const results = await this.db.bulkDocs(docs)
const conflicts = []
for (let n = 0; n < results.length; ++n) {
const result = results[n]
if (result.error === 'conflict') {
// TODO: This needs review...
const doc = await this.db.get(docs[n]._id)
const rev = `${doc._rev.split('-')[0]}-${this.serverName}`
conflicts.push({
...docs[n],
_rev: rev
})
this.revCache.set(doc._id, rev)
} else if (result.error) {
callback(result.error)
} else {
this.revCache.set(result.id, result.rev)
}
}
await this.db.bulkDocs(conflicts, { new_edits: false })
pouchdbから少しヒントを得ましたが、それを適用する方法がまだわかりません。
編集1：最新のコードで更新されました。
CouchDBは競合から自身を保護しようとするため、CouchDBが「認識している」ドキュメントのリビジョンを変更しようとすると、すでに置き換えられており、409応答が返されます。
レプリケーションが「それを回避する」方法は、ドキュメントがフラグ「new_edits = false」でターゲットマシンに一括書き込みされるためです。これは、CouchDBにリビジョントークンをポリシングするのではなく、着信トークンを受け入れるように指示します（レプリケーションソースからの書き込みにはすでに独自のリビジョンツリーがあります）。
あなたはこのような呼び出しでこれを自分で行うことができます：
ccurl -X POST -d '{"docs":[{"_id":"x","_rev":"1-myrevtoken","y":3}],"new_edits":false}' '/a/_bulk_docs'
この場合、すでに「リビジョン2」が含まれているドキュメントに2番目の「リビジョン1」を強制しました。
id = x
├─ 1
│ ├─ 1-myrevtoken
│ └─ 1-a6664c0114e6002415a47b18d4c9d32f
└─ 2-bca8f049e40b76dbfca560e132aa5c31 *
勝者はまだ「リビジョン2」ですが、リビジョン1での競合は、解決することを決定するまで未解決のままです。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加