PouchDB在成功複製刪除文件CouchDB的

創建在設備中的文件sale_transaction。
將sale_transaction文檔放在郵袋中。
因爲有袋&沙發之間的實時複製，讓sale_transaction文件流沙發上。
一旦sale_transaction文檔沙發的成功複製，刪除袋文檔。
請勿讓袋中的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，並想知道如果我在這個過程中做錯了什麼。

來源

2017-04-26 aamiel16

爲什麼不簡單地在內存中編輯/創建文檔，並將它們直接推送到CouchDB？ –

@AlexisCôté我正在考慮設備無法訪問互聯網的情況。因此，如果我將文檔推送到Pouch，並且沒有互聯網連接，我依靠Pouch的本地複製將文檔同步到Couch。 – aamiel16

對於像您在上面所描述的情況，我建議調整你的方法如下：

創建PouchDB數據庫從CouchDB的複製目標，但把這個數據庫作爲只讀的CouchDB數據庫的鏡像，應用您需要的任何轉換，以便從本地存儲中刪除某些文檔類型。爲了這個例子，我們稱這個數據庫爲mirror。 mirror數據庫僅通過變換複製從規範CouchDB數據庫單向更新。

創建一個單獨的 PouchDB數據庫來存儲所有的銷售交易。爲了我們這個例子，我們稱這個數據庫爲user-data。

當用戶創建一個新的銷售交易，本文件寫入user-data。聽取user-data上的更改，並在創建文檔時，使用更改處理程序創建文檔並將其直接寫入CouchDB。

此時，CouchDB正在從user-data接收銷售交易，但您的轉換複製正在阻止他們污染mirror。您可以將其保留，在這種情況下，user-data將擁有所有銷售交易的本地副本。在註銷時，您可以刪除user-data數據庫。或者，您可以在更改處理程序中添加一些更復雜的邏輯以在CouchDB收到文檔後刪除文檔。

如果你真的想變得花俏，你可以做更精心的事情。寫入CouchDB後將銷售事務處理保留在user-data中，並且在從CouchDB到mirror的變換複製中，查找這些新創建的銷售事務處理文檔。不要刪除它們，只要將它們除去它們的_id和_rev字段，然後將它們作爲「收據」使用。當其中一個ID與user-data中的ID匹配時，可以安全刪除該文檔。

無論您選擇哪種方法，我都建議您考慮將本地PouchDB的_changes供稿作爲工作隊列，而不是將所有這些複雜的邏輯放在複製過濾器中。上述方法應該都可以在離線情況下存在而不會引入衝突，並且在連接恢復時可以很好地恢復。我會推薦最後一個解決方案，儘管它可能比其他解決方案多一點。希望這可以幫助。

來源

2017-04-27 19:22:10 StickByAtlas

PouchDB在成功複製刪除文件CouchDB的

回答

相關問題