I'm aware of the three contexts and how they are used. What I was not clear on is if this new feature of using the new "localfilesystem" option is available outside of just flow.
e.g.
node.set("name", "value", "storeInFile");
global.set("name", "value", "storeInFile");
Which the Docs or the guide above did not cover. Granted the new comment below from @zenofmud however, does state that the "localfilesystem" option is available to all context scopes. e.g. node, flow & global
[this is a bit off-topic]
I had the same issue about Javascript functions that you may want to call from different places, so I raised a question on the forum, at the time on google groups.
I came up with a draft implementation https://github.com/iurly/node-red-contrib-shared-function which lets you store common code in a configuration node.
Not official, probably not optimal, but it serves my purpose so I ended up using it as-is all along.
Feel free to give it a try, hopefully we can revive the discussion!
Yes it works in a change node, but not that way. If you have two options defined in settings.js, you will see the following in the change node
which allows you to pick the type of storage you want to use.
If you only have one option, it uses and no choice is displayed.
@zenofmud, thanks for the clarification. Which is kind of strange, since I have a default store as memory and a second one as localfilesystem and both work when used in function nodes.
I have verified this both on disk, where the context folder with flow ID and json file is created and updated as well as in the flow.
Still I do not see this dropdown with the change node
Additional question: With reference to the cache setting, does this mean, a localfilesystem storage should also be accessible without specifying the exact context name, i.e. basically all items in this storage will also be copied over to memory?
Background to this question:
I have a flow where I stored some basic settings in the flow context. I switched this settings storage to a file context and all the nodes that read these settings are now no longer able to access them until I switch them to the file context as well.
As the settings are accessed read-only anyway, would it hurt to do:
No. The cache is an internal implementation detail of the file store. If you've defined a separate memory store, it has no relation to the internal cache of the file store.
Just noticed that if you set a flow variable in a file and you deploy, change it that variable to global and deploy -- Context Viewer still shows the old stored flow variable, even if it's not being used anywhere in the flow.
While writing this, I decided to try it with global variables as well -- if you create and set a persistent global variable, delete it, and re-deploy, just like the flow, the persistent global in file will be visible in the Context Viewer forever.
I guess there should be some type of persistent context garbage collection that happens during deploy.
err... persistent context means just that.....
If you have used a variable to set something into context we have no way of knowing in advance if you are going to refer to it again or not.
I do see your point â but if they are indeed contexts that were made in error, it makes it tedious to do an inject-change-delete-deploy, just to delete them (imagine defining 50 persistent global variables in a function and then later decide to change them to flow). At the least, and for consistency, there there should be a way to delete them in the Context Viewer -- just like how you can delete unused nodes in "Configuration Nodes". Just a suggestion.
