Hi Alumio,
I know you’re already working on searchable storages, and this request is somewhat similar, though not exactly the same. I’m guessing actually searching in the content of storage-entities is going to be quite resource heavy, and will likely require a whole “type” of storage.
We often need at least one more “identifier” column for storages. For example, I just had a case where the client wanted an Excelsheet created from an API datasource. But apparently, he wanted 2 Excelsheets for 2 different ways of calling that API. Because storages aren’t really ‘dynamic’, I had to do a lot of conditionals etc. to get those entities into the right bucket.
My proposal would be to add the option to storages to use a ‘grouping’ - basically just a nesting/folder into the filesystem.
Right now, when you do “Get an Entity From a Storage”, you have the option to:
- Select the storage
- Define the identifier (JMESPath possible)
- Define the destination
What if you’d also add the option for the folder, so you’d get:
- Select the storage
- Define the grouping/folder/nesting identifier (JMESPath possible)
- Define the identifier (JMESPath possible)
- Define the destination
If we get the same option in the ‘Get All Entities from a Storage’, we would already get half-way into a ‘searchable storage’ functionality.