PouchDBは、私は以下のような処理を実装しようとしていますCouchDBの

Question

に成功したレプリケーション時に文書を削除します。

1. デバイスでsale_transaction文書を作成します。
2. sale_transaction文書をポーチに入れてください。
3. ポーチ&ソファの間にライブレプリケーションが存在するため、sale_transactionのドキュメントをソーラーに流してください。
4. sale_transaction文書をCou​​chに正しく複製するには、文書をPouchで削除します。
5. ポーチの中のdeleted sale_transaction文書をカウチを通して流さないようにしてください。

現在のところ、両方のデータベースから双方向同期を実装しています。ここでは、私はCouchからPouchに送られる各ドキュメントをフィルタリングしています。逆もまた同様です。

CouchからPouchへの複製については、私はsale_transactionのドキュメントを通過させたくありませんでした。なぜなら私はCouchからこれらのドキュメントを取得できるからです。

PouchDb.replicate(remoteDb, localDb, { 
    // Replicate from Couch to Pouch 
    live: true, 
    retry: true, 
    filter: (doc) => { 
     return doc.doc_type!=="sale_transaction"; 
    } 
}) 

ポーチからソファーへのレプリケーションのために、私は通過するdeleted sale_transaction文書をさせないようにフィルターに入れながら。

PouchDb.replicate(localDb, remoteDb, { 
    // Replicate from Pouch to Couch 
    live: true, 
    retry: true, 
    filter: (doc) => { 
     if(doc.doc_type==="sale_transaction" && doc._deleted) { 
     // These are deleted transactions which I dont want to replicate to Couch 
     return false; 
     } 
     return true; 
    } 
}).on("change", (change) => { 
    // Handle change 
    replicateOutChangeHandler(change) 
}); 

また、私はソファーに書き込まれた後、ポーチにsale_transaction文書を削除するには、変更ハンドラを実装しました。

function replicateOutChangeHandler(change) { 
    for(let doc of change.docs) { 
     if(doc.doc_type==="sale_transaction" && !doc._deleted) { 
     localDb.upsert(doc._id, function(prevDoc) { 
      if(!prevDoc._deleted) { 
       prevDoc._deleted = true; 
      } 
      return prevDoc; 
     }).then((res)=>{ 
      console.log("Deleted Document After Replication",res); 
     }).catch((err)=>{ 
      console.error("Deleted Document After Replication (ERROR): ",err); 
     }) 
     } 
    } 
} 

データの流れが最初に動作しているようだが、私はソファーからsale_transactionドキュメントを取得するときに、その後、いくつかの編集を行う、私はその後、その後、ポーチ内のドキュメントを書くプロセスを繰り返す必要がありますそれをポーチに流してからポーチで削除してください。しかし、同じ文書を編集した後、Couchの文書も削除されました。

私はポーチでかなり新しいです&特にNoSQLの中のソファで、私がプロセスで何か間違っているのか不思議に思っていました。あなたは上記きたような状況では

Answer 1

次のように、私はあなたのアプローチを微調整することをお勧めしたい：

のCouchDBからのレプリケーションターゲットとしてPouchDBデータベースを作成しますが、読み取り専用としてこのデータベースを扱いますCouchDBデータベースのミラーで、ローカルストアから特定のドキュメントタイプを取り除くために必要な変換を適用します。この例のために、このデータベースをmirrorと呼ぶことにしましょう。 mirrorデータベースは、変換複製を使用して正規のCouchDBデータベースから一方向にのみ更新されます。

別途すべての販売取引を保存するデータベースを作成します。この例では、このデータベースをuser-dataと呼ぶことにしましょう。

ユーザーが新しい売買取引を作成すると、この文書はuser-dataに書き込まれます。 user-dataの変更を聞き、ドキュメントが作成されたら、変更ハンドラを使用してドキュメントを直接作成してCouchDBに書き込んでください。

この時点で、CouchDBはuser-dataから販売取引を受け取りますが、変換レプリケーションではmirrorが汚染されていません。あなたはそれを残すことができます。この場合、user-dataにはすべての販売取引のローカルコピーがあります。ログアウト時にuser-dataデータベースを削除するだけで済みます。あるいは、変更ハンドラに複雑なロジックを追加して、CouchDBが受け取ったドキュメントを削除することもできます。

あなたが本当に好奇心を得たい場合は、さらに手の込んだことができます。 user-dataをCouchDBに書き込んだ後、CouchDBからmirrorへのトランスフォーメーションレプリケーションで、これらの新しく作成されたセールストランザクション文書を探します。それらを削除する代わりに、_idと_revフィールドだけを削除し、これらを「領収書」として使用してください。これらのIDの1つがuser-dataのIDと一致すると、その文書を安全に削除できます。

どちらの方法を選んでも、この複雑なロジックをすべてレプリケーションフィルタに入れるのではなく、ローカルPouchDBの_changesフィードをワーカーキューとして考えることをお勧めします。上記の方法は、すべて競合を引き起こさずにオフラインのケースで生き残り、接続が回復したときにうまく回復する必要があります。私は最後の解決策をお勧めしますが、それは他のものよりもう少し仕事かもしれません。お役に立てれば。