Yes it does - just tested.
Although when the node config is examined, default is not displayed unless it is then selected.
Really the focus should go to flush out the limitations first. Without it, the feature is more unreliable than useful.
I think this is the result of the node being loaded from a flow file where its storeName is not defined. Once a value is selected and the node is re-deployed, it behaves as you would expect. Since this is a one-time issue (usually when upgrading from earlier versions), I haven't tried to come up with a fix.
P.S. I forgot to mention that this does not happen when a new instance of the node is created from the palette.
1 Like
The last time this came up, it was in regard to persisting the context of core nodes. This time, it concerns dashboard widgets. Using the queue-gate node as a pattern for doing this is just one possibility, and perhaps not the best one. As far as I can tell, the feature has worked reliably for the users of my nodes and not caused any confusion. If the community and developers come up with a method that can applied universally, I will be happy to use it. Meanwhile, suggestions for improvement of queue-gate, simple-gate and multiple-queue are welcome.
As far as I can tell, the editor only knows the context store names, and looking at the context store API (Context Store API : Node-RED), the runtime has no way of knowing if a given context store is persistent. So even if the editor had access to the same information the runtime has, there would still be no way to show/hide my proposed option checkbox.
So IF the context store API had a persistent flag (say ContextStore.persistent() returns true if the context store is persistent, false otherwise), and this is communicated to the editor via some RED.settings.context property (maybe not RED.settings.context.stores to maintain backwards compatibility) THEN it seems that the desired functionality of showing/hiding my proposed checkbox could be implemented. Obviously any changes like these are beyond the scope of the dashboard.
On a much smaller matter, @dceejay, I agree that storing state in the node context is better, no need to pollute the global context, I should have thought that through a bit more in my original proposal.
2 Likes
This illustrates how tricky the problem is. This flag might declare the intention of the developer of the context store to make it persistent, but variations in hardware and software among target systems might prevent it. For example, even localfilesystem cannot be guaranteed to be persistent. How would you suggest setting the flag in that case? Perhaps the answer is to define the flag in settings.js rather than in the module itself, but then the responsibility falls back onto the user, and the issue of sharing flows becomes even more complicated.
I think the current most obvious solution is for nodes (like dashboard) to only offer to persist data (on or off) and for that to only use the default store - as that will always exist.... it's then up to the user to actually ensure the default is actually persistent or not. It could perhaps also show the modulename used by default to give the user a clue what to expect (trickier if a required one.).
That way the majority of flows would still be shareable without editing or generating warnings.
Other specialist nodes can take a bolder approach and offer a choice of stores.
2 Likes
I think that is exactly the right approach, assuming that it is worth the developers' effort to modify some or all of the core nodes or dashboard widgets.
will do
The approach I have taken in my PoC is to use the callback function of the context store set method, and display a warning if it is signaled that the state could not be saved. A plugin that has the persistance flag set would indicate when a value could not be saved, just like any other (well-behaved) context store.
OK, I must be missing something. How exactly does the set method know that the storage is persistent?
I probably did not explain myself well. In the hypothetical case that the context store API at some point in time incorporates the capability to signal if a context store is persistent or not, and that this capability is communicated to the editor, that would take care of the UI being displayed or not, and give the user the choice of which persistent store to use, if appropriate.
Then to address your comment about hardware/software preventing a given store save operation to persist, even if the store has the persistance flag set, the set callback warning would serve to inform the user that something is amiss with the persistent store.
I understand the process, but I still suspect that the only way to be certain that the storage is persistent is to actually re-start Node-RED.
FYI, I published a collection of the standard dashboard input nodes implementing my proposal. I actually made it so that you can select the context in which to save the state, the variable to use, and the store to use. Obviously the state would only persist if the context store is persistent. I did not use the node context store because I could not find a way to configure the typedInput widget to select the node context but also select the context store.
I welcome any feedback on these nodes, which can be found here: node-red-contrib-dashboard-input-persistence (node) - Node-RED
I can't try them at the moment because I'm midway with making some changes myself, but I should get some time over the weekend.
It's unfortunate that this feature could not have been integrated into the standard ui node collection, especially as @dceejay seemed to be suggesting a compromised way forward;
I guess that door may still be open?
1 Like
Yes happy to consider a pull request.
I have no problems in contributing a PR, but I was under the impression that if it could not be guaranteed that there was a persistent context store then my proposal was a no-go. What would happen if the default context store is not persistent?
It would be up to the user to ensure that there is, and that would be documented in the node readme.
What would happen with your nodes if a persistent store was not available.
Same thing 
, but they are not the "official" Dashboard input nodes, which I gathered wanted to be as fail-safe as possible. I probably got the wrong impression.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
