Can't update import_filter via admin api

When attempting to update a database via the admin api on SG 2.8 I get the following result

{
    "error": "Bad Request",
    "reason": "Bad JSON: rest.DbConfig.ImportFilter: ReadString: expects \" or n, but found `, error found in #10 byte of ...|filter\": `\nfunction(|..., bigger context ...|ORG-office-WT\"]}\n    },\n        \"import_filter\": `\nfunction(doc) {\n    return true;\n}\n    `\n}|..."
}

The request body

{
    "server": "walrus:",
    "pool": "default",
    "bucket": "test-bucket",
    "name": "{{walrusdb}}",
    "users": {
        "user1": {"password": "password1", "admin_channels": ["USR-user1"]},
        "user2": {"password": "password2", "admin_channels": ["USR-user2", "ORG-office-RD"]},
        "user3": {"password": "password3", "admin_channels": ["USR-user3", "ORG-office-WT"]}
    },
    "import_filter": `function(doc) {
            return true;
    }`
}

The docs only show using back ticks for these settings. Is there another way to update import_filter and sync?

Use double quotes

{
    "server": "walrus:",
    "pool": "default",
    "bucket": "test-bucket",
    "name": "{{walrusdb}}",
    "users": {
        "user1": {"password": "password1", "admin_channels": ["USR-user1"]},
        "user2": {"password": "password2", "admin_channels": ["USR-user2", "ORG-office-RD"]},
        "user3": {"password": "password3", "admin_channels": ["USR-user3", "ORG-office-WT"]}
    },
   "import_filter": "\n              function(doc) {\n                return true;\n              }\n    "

}

Oh, do the back ticks not work anymore? The docs should be updated if not.

The sync function will have to go that route as well. Yikes. Is it common practice that folks are minifying the function before submitting it via api or the config file. (I noticed the config file also doesn’t like the backticks at all)

Not sure what you tried but backticks are required when using JSON config file and will work .

The double quotes is only if you are using REST API for updating config

(and that doc link is discussing the config file).

It’s talking about the sync function and only has the context of the JSON config file as a reference. I’ve not found any references to the api for managing the sync function so it seemed reasonable that the backticks needed to be applied in the API JSON as well. Plus my co-worker hasn’t been able to get the backticks to work in the config file.

I’m new to couchbase but not rdbms. It feels very weird to put application logic into a server config file.

I’ll review the docs and seek to clarify this area as needed – https://issues.couchbase.com/browse/DOC-7933

We will need more info on that like what was attempted, configured and logs etc. As documented, backticks must be specified in context of JSON config file and it will work.

We’ll update the doc with an example to show its use in context of API . However, there is a key reason why we have focussed on config file approach in our docs. Changes made via REST API are not persisted and won’t survive sync gateway restarts. So even if you change the config, you will lose it when you restart the sync gateway as the one defined in the config file will override.

Sync Function is a definition of sync gateway’s access control policies. So not quite “application logic”. But point noted.
There are a few product enhancement(s) on this front are on our radar. But at this time, use the config file for persistent changes.

:scream:OMG that is insane, and not mentioned in the docs. Does nothing in the admin api get persisted or just this one critical section?

As an ops person this is feeling like I need to give developers access to the mysql config file to update stored procedures. (I know that isn’t a real thing, but how I feel) brb, I need to wrap my head around this.

To clarify some:

Does this apply to all changes made via the API? Are users and roles not persisted such that a new sync gateway deploy would need to have them redefined via the admin API?

And does this only apply to config that is explicitly defined in the config file? If you were to leave the databases key out of the config.json file entirely, does a sync gateway deploy always insert defaults here which would override what was previously defined in the database?

Changes to users are persisted. Of course changes via the other REST calls to documents, (inter-sync gateway) replications etc will be persisted.

One dynamic config option you can consider using is configServer . However, note that this is deprecated …which means that this capability will be removed in a future release. When we do remove this, we will have alternate methods available on managing SGW config persistence (these are the aforementioned enhancements I spoke of). At that point, you’d have to update your solution to use new capability. So this is a stop gap solution.

Interesting. Are there any other docs on the configServer, response format and such?

So all other Admin API endpoints result in persisted changes and only the database API is not persisted?

Only the _config operation - anything to do with configuration with exception of user config is not persisted if doing with REST API. The database endpoint supports a number of other other non-config related functions .

Ok, that is more clear. Thank you

Started a diff post for the json config file issue with backticks