问题描述
我正在尝试解决CouchDB回滚导致PouchDB将来出现的问题。我想找到一种方法来检测这种情况,并在这种情况发生时强制PouchDB销毁并重新加载。
I am trying to cover for an issue where CouchDB is rolled back, causing PouchDB to be in the future. I want to find a way to detect this situation and force PouchDB to destroy and reload when this happens.
是否可以向PouchDB询问当前的拉序列号?我根本找不到任何文档。我的google-foo不够强大。
Is there a way to ask PouchDB for it's current pull seq number? I am not able to find any documentation at all on this. My google-foo is not strong enough.
到目前为止,我唯一的想法是观看sync.on(change)feed,并记录每次拉动的seq编号。然后在重新加载应用程序时,以ajax https:/ server / db / _changes?descending = true& limit = 1
运行此程序,并验证返回的seq数是否大于我存储的序列号。如果存储的seq较高,则使用pouchdb.destroy(),从indexdb中清除 _pouch _
,并可能想出如何删除此发行版的Websql版本。
So far my only thought is to watch the sync.on(change) feed, and record the seq number on every pull. Then on app reload, run this as ajax https:/server/db/_changes?descending=true&limit=1
and verify that the seq number this returns, is higher than the seq number I stored. If the stored seq is higher, then pouchdb.destroy(), purge _pouch_
from indexdb, and probably figure out how to delete websql versions for this release https://github.com/pouchdb/pouchdb/releases/tag/6.4.2.
还是有更好的方法来解决PouchDB将来会比CouchDB提前结束的情况?
Or is there a better way to solve situations where PouchDB ends up in the future ahead of CouchDB?
推荐答案
问题似乎出在复制检查点文档中。从备份中恢复数据库时,可能还在恢复检查点本地文档。
The problem seems to be in the replication checkpoint documents. When you recover a database from the backup, probably, you are recovering also the checkpoint local documents.
您应该删除所有本地文档,方法是使用_local_docs端点找到它们,然后从恢复的数据库中删除。
You should remove all local docs, by finding them with the _local_docs endpoint and then removing form the recovered database.
这样做,您的PouchDB应该尝试将同步回PouchDB和CouchDB的文档发送到CouchDB。
Doing this, your PouchDB should try to send to CouchDB their docs syncing back PouchDB and CouchDB.
这篇关于是否可以获得最新的PouchDB序列号?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!