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
b7014f4dbb
commit
a8c6fe7687
@ -269,19 +269,27 @@ My proposal is as follows. Do you agree with this option?
|
|||||||
#### How to get keys in the external storage
|
#### How to get keys in the external storage
|
||||||
In [Usage](#usage),
|
In [Usage](#usage),
|
||||||
> If you want to access the external storage, add the prefix(*) to the key of context data as follows.
|
> 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?
|
Currently,`keys()` needs no arguments. How we get all keys in the external storage?
|
||||||
|
|
||||||
1. Adding a parameter to `keys()`
|
1. Adding a parameter to `keys()`
|
||||||
`keys("$identifier")` returns all keys in the specified storage.
|
`keys("$identifier")` returns all keys in the specified storage.
|
||||||
If `$identifier` is `null` or `undefined`, `keys()` return all keys in the memory context.
|
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.
|
If you use a LocalFileSystem plugin as `$file`, `keys("$file")` returns all keys in the LocalFileSystem context.
|
||||||
|
* Pros: You can get keys from the specified storage. You can also get keys from the memory context in the same way as current. i.e. `flow.keys()`
|
||||||
|
* Cons: `keys()` usage changes.
|
||||||
|
|
||||||
2. No arguments same as current
|
2. No arguments same as current
|
||||||
a. `keys()` returns all keys in all external storage.
|
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 you use 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.
|
If this is chosen, we have to discuss about returned keys format.
|
||||||
|
* Pros: You can use `keys()` with no arguments as before.
|
||||||
|
* Cons: You cannot get keys from the specified storage.
|
||||||
|
|
||||||
b. `keys()` returns all keys in the memory context.
|
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()`.
|
Node-RED don't provide the interface of `keys` to plugin. So you cannot get all keys by `keys()`.
|
||||||
If a plugin wants to returns keys, it will use `run()` to return keys.
|
If a plugin wants to returns keys, it will use `run()` to return keys.
|
||||||
|
* Pros: You can use `keys()` with no arguments as before.
|
||||||
|
* Cons: You cannot get keys from the external storage by `keys()`
|
||||||
|
|
||||||
|
> HU: I prefer number 1. I think that the cons is small impact same as set/get.
|
Loading…
Reference in New Issue
Block a user