Conversation
|
Trival change in names didnt impact tests. |
|
@josephxsxn unfortunately making the change this way would be rather disruptive to existing flows. We learned this lesson on PropertyDescriptor object and for that we added an additional characteristic called 'displayName'. What I'm suggesting is we do the same for Relationship. By adding a 'displayName' we can allow developers to change/tweak that over time whereas the 'name' cannot change once it is put out in a release unless the change is made during a major release cycle and even then we should try to minimize the frequency since it can make porting flows harder. The bottom line is the 'name' is an important part of how we establish the persistent knowledge of a connection between two components. If you look in the flow.xml.gz of a flow with a connection you'll see the 'relationship' and in it is the name of the source processors relationship used in that connection. So, changing the 'name' breaks old flows. We can instead add 'displayName' and now that value is what will show up in the UI but is not what is used for underlying persistence. By default the displayName if not set will be whatever the name was (and vice versa) in the code just like PropertyDescriptor but over time the value of name and displayName can diverge and that will be ok provided the Relationship still means what it meant before. I'll stop rambling. Does this make sense? |
|
@josephxsxn in light of Joe's comments, would you like to close this PR? Cheers! |
|
Closed in light of Joes comments. |
Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
Has your PR been rebased against the latest commit within the target branch (typically master)?
Is your initial contribution a single, squashed commit?
For code changes:
For documentation related changes:
Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.