Did anyone test service-runner with a non-null dbnum?
My expectation is that service-runner is unaware of this and if you choose any other dbnum apart from '', service-runner and all Modules that use it will cease to trigger on a service-runner flag.
It should certainly be noted in the comments in the settings file that changing dbnum will cause service-runner to no longer trigger. While we’re updating the settings file, until the service-runner flag has its own code that always uses the same prefix, it’s probably also worth adding as comment that changing the prefix from emoncms or '' also breaks service-runner.
I did suggest the comment was added regarding the prefix.
1 Like
only the core emoncms supports multiple databases, it’s not implemented in the other modules.
This did cross my mind when looking at service-runner, but I didn’t pursue it as it raised further questions about which Redis database would the service-runner connect to if there are multiple Redis databases? Presumably multiple databases would be used when there are multiple emoncms instances, so do we then need a single database for service-runner across instances??
TBH I was a bit surprised to see the multiple database option merged since it seems widely documented that "Use of multiple database in same server instance is discouraged and deprecated " and that’s why we use prefix’s.
I looked into this way back when I first ever created a multi(emoncms) instance server, I wanted to use separate db’s so that the flush command worked, but I was dissuaded by the general consensus that it was bad form to have multiple databases on one Redis server. Although “deprecated” for several years, it’s still possible it would seem.
Perhaps a decision needs to be made as to whether emoncms really needs to support multi-db’s and invest in supporting something that isn’t widely used, or not.
(a quick search found c# - Why using multiple database in same instance a bad idea in Redis? - Stack Overflow which links to a couple of discussions, but I have read it in many places)
1 Like
Unless it creates work supporting it (I suspect this might only be used when the connection is created - don’t know) I’d be inclined to leave it be now and simply put a comment that says “don’t touch these settings unless you really know what you are doing” plus some comments on the impact to service-runner for those that need to change them.
Good points re dbnum, the changes to support this where very small (redis: support db selection via dbnum config · emoncms/emoncms@67a36a2 · GitHub) and I thought if its useful for particular users then why not - but your right, it has knock on effects if there is assumed support in other emoncms components.
We could remove dbnum from default.settings.php but keep the check in index.php for advanced users keen to use this/using this already.
Happy to add notes for both the prefix and dbnum in the default settings file
2 Likes
I think that should cover it - as long as people know the consequences (and can see those documented at the point where they’re making the change) there seems little actual risk in leaving it available.
2 Likes