[jira] [Comment Edited] (NIFIREG-231) NiFi Registry variable registry hierarchy problem

["Nimrod Avni (JIRA)" <ji...@apache.org>]

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

Nimrod Avni edited comment on NIFIREG-231 at 3/15/19 6:31 PM:
--------------------------------------------------------------

[~bende] I understand and agree that the registry should monitor variables from an outer process group (if they are being used in the flow itself), but it does create a difficulty understanding which variables are flow specific and which ones are global variables for more then this one process group.

In our usecase we want to develop the flow in our development environment, where we have some global variables set, when we deploy it to our production environment (which have the same global variables, maybe with different values) we want to know (using the registry api) which variables are flow specific so we can configure them, and which ones are not set inside the committed pg (the global variables).

When you commit a pg you know which variables you are using and where are they in the hierarchy, i'm not suggesting to keep the full hierarchy of each variable, perhaps a flag that states if the variable used is from the committed process group or set from an external process group, or maybe a different key for variables set outside the committed pg, to help differentiate between variables from the variable registry in the commited process group and variables from a variable registry higher in the hierarchy that are used in the flow, which (In my opinion) have different meanings


was (Author: max kelada):
[~bende] I understand and agree that the registry should monitor variables from an outer process group (if they are being used in the flow itself), but it does create a difficulty understanding which variables are flow specific and which ones are global variables for more then this one process group.

In our usecase we want to develop the flow in our development environment, where we have some global variables set, when we deploy it to our production environment (which have the same global variables, maybe with different values) we want to know (using the registry api) which variables are flow specific so we can configure them, and which ones are not set inside the committed pg (the global variables).

When you commit a pg you know which variables you are using and where are they in the hierarchy, i'm not suggesting to keep the full hierarchy of each variable, perhaps a flag that states if the variable used is from the committed process group or set from an external process group, or maybe a different key for variables set outside the committed pg, to help differentiate between flow specific variables and global variables that are used in the flow, which (In my opinion) have different meanings

> NiFi Registry variable registry hierarchy problem
> -------------------------------------------------
>
>                 Key: NIFIREG-231
>                 URL: https://issues.apache.org/jira/browse/NIFIREG-231
>             Project: NiFi Registry
>          Issue Type: Bug
>    Affects Versions: 0.3.0
>            Reporter: Nimrod Avni
>            Priority: Major
>              Labels: scope, variable-registry
>         Attachments: RegistryResponse.PNG, nifiVariableRegistry.PNG
>
>
> We have ran into the where i am building my flow, and i am using variables from the variable registry from a scope outside of my current process group. as well as variables from the scope of my current process group
> After committing the flow i sent a GET request to :
> <<nifi-registy-url>>/nifi-registry-api/buckets/<<bucket-id>>/flows/<<flow-id>>/versions/<<current-version>>
> when looking inside the flow/flowContents/variables section i saw both variables, one from the outer scope of the process group and one from scope of the versioned flow with no way to tell them apart, there should be a way to tell apart these two variables.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)