added proposal of optional list-like representation

Hiroyasu Nishiyama 2017-07-20 12:15:41 +09:00
parent 321a9a1f4b
commit ac64165c18
1 changed files with 15 additions and 1 deletions

@ -32,3 +32,17 @@ What the current behaviour allows is that the join can be manipulated by changin
However - while this makes sense for strings and objects - may need some thinking about for consequences for arrays as currently we try to preserve order in the array. So what does removing or inserting mean in this context - or rather what should the behaviour actually be.
### Proposal: optional list-like representation
The `msg.parts` is adequate tool for doing list-like operations with a Node-RED flow. For example, filtering messages in a message stream or inserting messages to a message stream is useful for handling messages with some relation. However, changing message counts of a message stream needs sotring whole messages in the stream then changing `msg.parts.count` and `msg.parts.index`. For short streams, this should never be a problem. However, for long streams keeping and changing all messages in a message stream may raise problems such as increased memory usage or delay in messages.
So as a optional representation of `msg.parts`,
we propose following linked list representation:
name | type | mandatory | description
------------ | ------------- | ------------ | ------------
next | string | yes | `msg.id` of next message
Either `parts.count` and `parts.index`, or `parts.next` can be used at the same time.
Insertion or deletion of messages with list-like representation can be implemented by keeping smaller number of messages.
Selection of old array-like representation or list-like representation should be selected by producer nodes. Conversion nodes betwee two prepresentations considered to be useful.