Bence, This is a really well-crafted proposal and I think it would be helpful to a lot of people. Are you comfortable opening a Jira for this feature? I think in addition to providing the functionality, we would need to generate some helpful and clear documentation and perhaps even suggest the filters in the search UI/UX, as people will only use the feature if they are aware of it.
Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Feb 21, 2020, at 10:42 AM, Martin Ebert <[email protected]> wrote: > > We still think about building a graph based search (Neo4j) in top of NiFi. > Would be also fantastic to have it within NiFi. > > There are plenty of examples > https://blog.grandstack.io/using-neo4js-full-text-search-with-graphql-e3fa484de2ea > From the idea it could go in this direction - of course much more > rudimentary. Then one would have the possibility to have only the results > displayed as text or to find out exploratory connections (graph layout). > The built-in data lineage function of NiFi would also benefit from the > power of Neo4j. > > Simon Bence <[email protected]> schrieb am Fr., 21. Feb. 2020, 19:00: > >> 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 >>
