Simon Bence created NIFI-7188:
---------------------------------
Summary: Extending search capabilities with filters
Key: NIFI-7188
URL: https://issues.apache.org/jira/browse/NIFI-7188
Project: Apache NiFi
Issue Type: New Feature
Components: Core UI
Reporter: Simon Bence
Assignee: Simon Bence
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. Note: the filter does
not look for full match but if the group name contains the filter value. This
is needed to keep the "spaceless" format of the filters, as the group name
might contain space. In a later point, we might add a more sophisticated query
string processing, might parse strings between quotations.
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.
As part of the feature development I plan to update the documentation with the
new functionality.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
