Well they can use it if enabled as long as they also handle the case when it isn’t
It is a very nice feature for which I have one question:
When using persistent context: is there also an easy way to flush (reset) the persistent context ?
With flushing (resetting) I mean that you delete everything that is stored in the persistent context.
When debugging or testing new flows it might be interesting to be able to flush the persistent context.
This is especially valuable if due to an error you have stored incorrect state information in the persistent context.
No, there is no 'one-click' way of clearing persistence. You would need to create an Inject-triggered flow that clears any values you want clearing - just as you would today for setting any default/initial values.
Yes, I generally set up a flow with 2 input triggers, one for dumping variables to debug and one for clearing them.
0.19 includes a new sidebar panel that lets you see the contents of context - very similar to the context-browser node, but built around the new underlying apis.
2 Likes
Then might there be a master "Reset" button available in the sidebar, at some point?
One day there “might” be. But is not in plan for the near future, so don’t hold your breath.
Is it possible to have a write delay or min time between writes option in this persistent storage system?
The default Node Red install in Raspbian (2018-03-13-raspbian-stretch-lite) destroyed my SD Card with an error in their Systemd configuration that caused a log flood that I did not catch until tracking down why it had failed and since then I've been a bit shy about automatic writes in relation to Node Red.
Given that Node Red is widely deployed on Raspbian using SD Cards now, this might be a good feature.
Thank you
Chisight
See me on IRC at ircs://freenode:6697/##nodered and ircs://freenode:6697/#mysensors
1 Like
It isn't I want to make people cringe when I ask questions but I see a "problem":
And I may not be very good with what I do and/or how I do it, but I do foresee a trap/problem.
The upgrade will allow (at user's choice) that variables remain even on a FULL DEPLOY.
(for perspective)
Now, I know it is my own fault that sometimes I use the quickest deploy (modified nodes) and not always FULL.
Going to the new option and keeping things active even on a FULL DEPLOY can cause new people grief (well, I'm just saying) that if they make a mistake and do a FULL DEPLOY (which granted they set to KEEP VARIABLES ALIVE) and the problem doesn't clear because of their erroneously setting a variable; will there be a way to wipe them?
As it is, the user can use a FULL DEPLOY to reset all the variables/contexts, and so if something wasn't set right it would be wiped. That is useful in that respect.
How would this be done if NR is set to keep variables active even on a FULL DEPLOY?
(Does that make sense?)
Hi, this is a sensible question and is answered by Nick above:
To clear the persistent variable, you create a very simple flow that is manually triggered via an inject node. It would delete or reset the variable according to need. If really stuck, I expect that you could also delete (or better rename) the file(s) that contain that data.
If it is a global variable, it may be possible to change settings.js as well but we will need to see what preference order is being used.
1 Like
Thanks - again.
Just wanted to check.
