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 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)
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.
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.
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.
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.
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 .