Dear Community,
In my project, I do use relatively high number of processors and process
groups. The current search function on the NiFi UI has no capabilitites to
narrow the results based on the group, which would make the results more
relevant, so I would like to propose a possible solution. Please if you
have any comment on this, do not hesitate to share it.
The general approach would be to keep the current text box and extend the
server side capabilities to process search query in the similar manner for
example the Google search behaves.This extensions I would call "filters".
For now I am interested in the ones I will mention below, but I think, it
is only a matter of small work for further extend the solution with further
ones.
In order to distinguish the filters from the rest of the search query, I
propose to put them at the beginning of the query and use the
[a-zA-Z0-9\.]{1..n}\:[a-zA-Z0-9\.]{1..n} format. For example a filter might
look the following: lorem:ipsum
Adding this, the search query should look like the following:
filter1:value filter2:value rest of the query
As for processing the filters, I suggest the following behaviour:
- Without filters the current behaviour should be kept
- Everything after the filters should be handled as the search term
- After the first "non filter word", anything should be considered as part
of the search term (meaning: to keep the text parsing simple, I would not
go in the direction to support filters at the end of the query, etc.)
- The ordering of the filters should have no effect on the result
- Filter duplications should be eliminated
- In case a filter appears multiple times in the query, the first occasion
will be used
- Unknown filters should be ignored
- Only adding filters will not end up with result, at least one character
must appear as search term
Suggested filters:
scope
Narrows the search based on the user's currently active process group. The
allowed values are: "all" and "here". All produces the current behaviour,
thus no filtering happens, but "here" should use the current process group
as "root" of the search, ignoring everything else (including parent group).
Note: This needs a minimal frontend change, because as I did see, currently
the current group is not sent with the search query.
group
Narrows the search for a given processing group, if it exists. The
behaviour is recursive, thus the result will include the contained groups
as well. If it is a non-existing group, the result list should be empty.
properties
Controls if properties values are included or not. If not provided, the
property values will be included. This is because in a lot of cases there
is a huge number of results come from property names.
- Valid values for inclusion: yes, true, include, 1
- Valid values for exclusion: no, none, false, exclude, 0
It is possible that the range of possible values should be limited (and not
being ambiguous), but I see a merit of "permissiveness" here as it is
simpler to remember.
Also some example:
1.
scope:here properties:exclude lorem ipsum
This should search only in the current group (and it's children), excluding
properties and return with components containing the "lorem ipsum"
expression.
2.
group:myGroup someQuery
This should result the finding of components with someQuery expression, but
only within the myGroup group, even if it is not the active one.
3.
scope:all properties:include lorem
This should behave the same as "lorem" without filters.
Thanks for reading, I am interested to hear your opinion!
Kind regards,
Bence
