Major Description
What is the problem?
In a discussion with Ben Brooks I asked whether the data Sync Gateway stores in the _system scope will work if the collections are renamed (using map-data) or we exclude scopes/collections. He indicated that it may not:
I think what'll happen is SG is going to try and open the collection and find it no longer exists. The customer will have the option of repairing this by updating the database config to remove the non-existent collection.
It's the same behaviour that exists today if a customer went and just deleted a collection from the bucket when a SG database was referring to it.
Is this a regression?
I do not believe so. The data that is now in the _system scope used to be stored in the _default collection. The location has changed but the behaviour here hasn't.
What is the solution?
For non-KV services we ask them to provide a backup endpoint that returns an opaque blob of JSON. On restore we then give them this blob back along with the remapping/including/excluding that we are doing and they are responsible for affecting the change. We could potentially do a similar thing here but currently cbbackupmgr does not know anything about SG