mirror of
https://github.com/node-red/node-red.git
synced 2023-10-10 13:36:53 +02:00
Updated Design: Persistable Context (markdown)
parent
7cae451e4d
commit
24e72ec4d3
@ -194,3 +194,23 @@ My proposal is as follows. Do you agree with this option?
|
||||
- Encourage a unique key name by writing it on design note.
|
||||
|
||||
> NOL: agreed - fall back to the `default` store, and remove the store name from the key. I think having multiple storage plugins will be rare, so this is an very much an edge case.
|
||||
|
||||
#### How to get keys in the external storage
|
||||
In [Usage](#usage),
|
||||
> If you want to access the external storage, add the prefix(*) to the key of context data as follows.
|
||||
Currently,`keys()` needs no arguments.
|
||||
How we get all keys in the external storage?
|
||||
|
||||
1. Adding a parameter to `keys()`
|
||||
`keys("$identifier")` returns all keys in the specified storage.
|
||||
If `$identifier` is `null` or `undefined`, `keys()` return all keys in the memory context.
|
||||
If a user uses a LocalFileSystem plugin as `$file`, `keys("$file")` returns all keys in the LocalFileSystem context.
|
||||
|
||||
2. No arguments same as current
|
||||
a. `keys()` returns all keys in all external storage.
|
||||
If a user uses a LocalFileSystem plugin, `keys()` returns all keys in the memory and LocalFileSystem context.
|
||||
If this is chosen, we have to discuss about returned keys format.
|
||||
|
||||
b. `keys()` returns all keys in the memory context.
|
||||
Node-RED don't provide the interface of `keys` to plugin. So a user cannot get all keys by `keys()`.
|
||||
If a plugin wants to returns keys, it will use `run()` to return keys.
|
Loading…
Reference in New Issue
Block a user