What are some general examples or reasons to delete a message property?
https://cookbook.nodered.org/basic/delete-message-property
Maybe one instance is when a payload is split up, following different branches...
What are some general examples or reasons to delete a message property?
https://cookbook.nodered.org/basic/delete-message-property
Maybe one instance is when a payload is split up, following different branches...
Maybe you need to save msg.payload before using a node that over writes msg.payload and then you need to move the data back to msg.payload for some other reason, so you do some clean up.
There are a number of reasons why you may want to delete a message property:
If you have a flow that branches, each branch will get a clone of the message. If you have a message property containing a very large object that you don't need anymore, it would be much more efficient to delete that property before the flow branches.
There are some commonly used message properties that affect the behaviour of nodes. For example, msg.topic
, msg.reset
and others. You may need to delete that property after passing it to Node A to stop it affecting Node B later on in the flow.
Similar to #2, some of the network I/O nodes (TCP, UDP, WebSocket) set a property called msg._session
that identifies the source of a message. If you pass a message with that msg._session
property set to a corresponding Output node, the node will send the message back to the original sender. However, you may want to broadcast out to all connected clients, so you'd delete msg._session
.
Some storage nodes have an option to store the complete message object - some of the Mongo nodes for example, So you may want to delete properties on the message you don't want storing in the database.
I'm sure there will be plenty of other reasons why you may need to delete a message property.
Can I just ask then:
I send a message into a node - say: trigger
.
It has msg.reset
to true
.
That message stops at the trigger
node - doesn't it?
Or do you mean that because I usually have that constructed else where and therefore no other stuff I don't see the message coming out because there is nothing left to send?
To expand on that slightly:
So if I sent out of what ever node: {msg.payload:"foo",msg.reset:true}
into the trigger
node I would get foo
out of the trigger node?
To further confuse the issue, I tried that and it doesn't work as I just explained.
(code)
[{"id":"2cef468.1f5173a","type":"trigger","z":"5b6dee10.d1621","name":"","op1":"1","op2":"0","op1type":"str","op2type":"str","duration":"50","extend":false,"overrideDelay":false,"units":"s","reset":"","bytopic":"all","topic":"topic","outputs":1,"x":830,"y":1650,"wires":[["2bdef8e7.a379e8"]]},{"id":"2bdef8e7.a379e8","type":"debug","z":"5b6dee10.d1621","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1060,"y":1650,"wires":[]},{"id":"1d7ffa5b.22f4d6","type":"inject","z":"5b6dee10.d1621","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":660,"y":1580,"wires":[["2cef468.1f5173a"]]},{"id":"73eaea20.b2e5d4","type":"inject","z":"5b6dee10.d1621","name":"","props":[{"p":"payload"},{"p":"reset","v":"true","vt":"bool"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"foo","payloadType":"str","x":660,"y":1650,"wires":[["2cef468.1f5173a"]]}]
Thanks.
I think you are over thinking msg.reset in relation to the trigger node. Stated is " If the node receives a message with a reset
property, or a payload
that matches that configured in the node, any timeout or repeat currently in progress will be cleared and no message triggered."
The last three words are the key.
@knolleary stated " You may need to delete that property ...". In the case of the trigger node, passing in msg.reset deletes the whole msg, there is nothing left to delete.
Your example demonstrates this I think?
Yeah, I seem to live at the two extremes.
Either not thinking about it or over thinking it.
Another use case: I often delete the msg.topic
after database nodes. Since some queries can be quite long, it makes using the debug panel harder to read if the topic is too long.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.