I am trying out Context to save variables across a reboot.
It is working fine and I have the timer set at the default 30 seconds.
However, as a test, I replaced a value with the identical value and then did a flow.set(xxxx,"storeInFile") and I am finding that it has resaved the file (as shown by a date -r json.flow) despite there not actually being a change in the contents.
I was under the belief that the file was only rewritten back to the SD card if there is actually a change to write?
But you did call flow.set. I don't think in the current implementation the store checks the value to see if it has changed. Just calling flow.set is enough to mark it as needing to flush a write out.
Yes I did call flow.set as I wasn't thinking that I had to check for data changes.
If I don't do the flow.set then I am not persisting data across a reboot?
I must have got the wrong end of the stick.
It looks like I will have to do a flow.get, then compare the retrieved value with my new value and only do a flow.set if different..
That might be a bit drastic.
I know the default rewrite time is 30 seconds and as Nick said, it was with the intent of minimising rewrites back to a SD card.
Maybe I was then expecting too much and putting 2 and 2 together in thinking that it would only rewrite actual changes for the same reason of limiting writes to the SD card.
well I guess it could be optimised further, but then you have to balance the performance impact of checking every item to write vs the write wear. (I have no idea how to compare those apples vs oranges)
Just to add - it would be trivial to do the check if we're checking discrete values - such as a String, boolean or number. And I suspect there's some low-hanging optimisation-fruit to be had with those cases.
It gets harder when the thing being stored is an Object - which can arbitrary depth and complexity. That's the case that would be relatively expensive to check for changes.
I can manage it myself now I know!