Where to find the _removed flag for a document that stoped matching a channel?


#1

Hi Folks :sunny:,

I am working on a very basic scenario with channels, namely i have:

  • SyncGateway1.5.1, CouchbaseLite 1.4.1, Xamarin Forms App running on Android.
  • A sync function that assigns a channel to each document according to its “Type” property.
  • An app with a pull replicator whose Channels property (filter) is set to a single channel: “X”.

Now, if i create a document with Type “X”, the document syncs correctly to my App’s CBLite.

Then, lets say that i edit the document so that Type is now “Y”.

The SyncGateway log does notify me through its Changes feed that a channel was removed from the document and the document is synced to my App. According to the documentation, this new revision being synced to my App should contain a “_removed” flag so that i can manage the channel change of the document… but i can not find such flag anywhere in the incoming document…

Could anyone tell me where exactly can i get that “removed” (either with value true or false) flag in a pulled document in my App?


#2

Have you checked the IsGone property of the retrieved document?


#3

Hi @borrrden ,

Thanks for your reply.

I took a second look and did some further tests just to find out that the reason i see no notification on my App side seems to be that i am setting the Channels property/filter in the Pull replicator in the App, and not in the SG’s config file.

Indeed, if i set the Channels for the user directly in the SyncGateway’s (SG) config file (as a value to admin_channels), whenever a document stops matching those channels i get the IsGone:true notification in the App in the next synced current revision of that document, as you suggested. But that does not happen if instead i set the Channels property/filter in the Pull replicator in the App (in that case IsGone is always false!).

FYI, the SG config file i use looks like this:

{
  "interface": ":4984",
  "adminInterface": ":4985",
  "log": [ "CRUD", "Changes+" ],  
  "databases": {
    "cb": {
      "server": "http://localhost:8091",
      "bucket": "sync_gateway",
      "enable_shared_bucket_access": true,
      "import_docs": "continuous",
      "username": "user",
      "password": "userSG",
      "users": {
        "GUEST": {
          "disabled": true,
          "admin_channels": [ "*" ]
        },
        "user": {
          "password": "Password",
          "admin_channels": [ "*" ]
        },
        "synckuhnleapps": {
          "password": "Password",
          "admin_channels": [ "*" ]
        }
      },
      "sync": `function(doc)
      {
        if (doc.sys.Type == "MobileEinstellungen")
        {
          if (doc.usr.DeviceID == "")
          {
            channel("gME");
          }
          else 
          {
            channel(doc.usr.DeviceID);
          }
        }
        else if (doc.sys.Type == "Adressen")
        {
          channel("Adressen_Kundengruppe:" +
          doc.usr.Kundengruppe);
        }
        else 
          channel(doc.sys.Type);
      }
      `
    }
  }
}

So, is there still any chance i can get any notification if i work only with the Channels filter in the Pull replicator?


#4

No; in this case you still have access to the document, the app is just not pulling updates. The _removed property is only if you lose access to the document.


#5

Yes you are right, i still have access to the document.
Nevertheless, since the channel routing logic is written in the SG’s config file, i have no way to know if an incoming synced document stopped matching the channels set as filters in my App’s pull replicator. In my opinion it would be helpful to still get a flag set by SG. Or… is there any simple way to know if a document stoped matching the channels/filter of the App that i am missing? :face_with_raised_eyebrow:


#6

No, unfortunately there isn’t.

(This kind of in-to-out state transition is very difficult to implement scalably in SG, and the replicator and CBL don’t have a way to represent something like ‘this doc used to be in a channel but isn’t anymore’, so there would be major architectural work to implement a feature like this.)


#7

Thanks @jens, your answers have shed some light on what i can and can not do with Couchbase Lite.