[ 
https://issues.apache.org/jira/browse/NIFI-4707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298653#comment-16298653
 ] 

ASF GitHub Bot commented on NIFI-4707:
--------------------------------------

Github user mattyb149 commented on the issue:

    https://github.com/apache/nifi/pull/2351
  
    Thanks for the commit, great stuff!  Do you think the processing of the 
stack for each record will be ok in terms of performance impact?  I wonder if 
we'd be better off building a tree (basically a flow graph model) when building 
a component map, along with another "index" map from component id -> node in 
the tree. It might replace the need for other "inheritance" maps or property 
maps (as the node could hold the properties). Then we can get the component and 
traverse to the root during the filter?


> SiteToSiteProvenanceReportingTask not returning correct metadata
> ----------------------------------------------------------------
>
>                 Key: NIFI-4707
>                 URL: https://issues.apache.org/jira/browse/NIFI-4707
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Extensions
>            Reporter: Matt Burgess
>            Assignee: Matt Burgess
>
> When the SiteToSiteProvenanceReportingTask emits flow files, some of them 
> include a "componentName" field and some do not. Investigation shows that 
> only the components (except connections) in the root process group have that 
> field populated. Having this information can be very helpful to the user, 
> even though the names might be duplicated, there would be a mapping between a 
> component's ID and its name. At the very least the behavior (i.e. component 
> name being available) should be consistent.
> Having a full map (by traversing the entire flow) also opens up the ability 
> to include Process Group information for the various components. The 
> reporting task could include the parent Process Group identifier and/or name, 
> with perhaps a special ID for the root PG's "parent", such as "@ROOT@" or 
> something unique.
> This could also allow for a PG ID in the list of filtered "component IDs", 
> where any provenance event for a processor in a particular PG could be 
> included in a filter when that PG's ID is in the filter list.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to