CouchDB/PouchDB Selectors not syncing properly - couchdb

Question

I have set up a selector and my pouchDB syncs documents based on that selector.
Here is the selector. It will get all documents of type="job" and that include 1371 ID in permission array OR any document of type="load".
const myselector = {
$or: [
{
type: {
$eq: 'job'
},
permission: {
$elemMatch: { $eq: 1371 }
}
},
{
type: {
$eq: 'load'
}
}
]}
Here's how I sync
this.db.replicate
.from(this.remoteDB, {
selector: myselector
})
.on('complete', info => {
// then two-way, continuous, retriable sync
this.db
.sync(this.remoteDB, {
live: true,
retry: true,
selector: myselector
})
.on('change', change => {
console.log('my change0', change);
})
.on('error', error => {
console.log('my error', error);
});
})
.on('error', error => {
console.log('my error2', error);
});
This works perfectly and tells me if theres a change in any document but If e.g I make a change in permissions array and id 1371 gets changed then it doesnot notify me of the change. Now if I change any other field in that document, it doesnot get replicated as its not been synced anymore.
I'm using Selector instead of CouchDB Filters as they're apparently 10x faster but this sync becomes a problem.
If the document gets changed and doesnot fall in the selector criteria anymore then the change function is not called.

Answer 1

The behaviour you described is correct.
The filtered changes feed only includes the documents that currently match the selector conditions. The filtering is not considering the previous state of the document.
This question exposes a similar issue: CouchDB filter function and continuous feed
I see 2 approaches to manage this:
Make filtering data part of the document identity:
Design your docs by including the filtering attributes as part of the document IDs, so the change of any of the filtering attributes should be managed as a deletion and a creation of a new document. The local database will contain only the valid documents.
Keep history of the filtering data in the doc:
You should keep the history of the values of the filtering attributes in the documents and expand your selector to check the current and old values. In this case, is your client application the responsible to determine which of the documents in the local database are valid in a moment as not every document in the local database is valid for the client.