[
https://issues.apache.org/jira/browse/NIFI-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15367101#comment-15367101
]
ASF GitHub Bot commented on NIFI-826:
-------------------------------------
Github user olegz commented on the issue:
https://github.com/apache/nifi/pull/617
Quick design notes:
The implementation is primarily based on utilizing time-based (Type-1) UUID
since NiFi and all of its components has already embraced UUID as identifier.
It is also based on recognizing that UUID is a 128-bits two-part value
(_lsb_ and _msb_ - see UUID javadoc for more details) essentially able to hold
(with a bit of an effort) two fairly unique identifiers allowing it to hold
- inception ID - immutable ID of the component regardless how many times it
was re-created
- instance ID - unique identifier of a component instance.
When component is created for the first time the _inception ID_ (i.e.,
time) is created from the current time while _instance ID_ remain random. The
combination of two will result in the typical UUID
```c81f6810-0155-1000-0000-c4af042cb1559```. The _msb_
```c81f6810-0155-1000-0000``` represents the time the component was created
while the _lsb_ ```c4af042cb1559``` represents the instance id.
The above essentially addresses the original discussion in the JIRA about
having two IDs.
However, in addition and given that this new ID is Type 1 UUID
(time-based), the components are now deterministically sortable based on their
IDs.
Last but not least, when components are persisted to the template, the
_instance ID_ is removed while _inception ID_ remains essentially preserving
all the connectivity between the components while elimination the ID changes to
the same component every time it is saved. Using the above example, the
serialized ID of the above component will be
```c81f6810-0155-1000-0000-0000000000000```
@mcgilman - As you and I discussed there were an issue with imported
templates honoring the original coordinates of the components. The way I fixed
it is by removing some of the code (see
https://github.com/apache/nifi/pull/617/commits/a52092513b15f2e3ea860ba909f8e59d4bf96be1#diff-a5bebdfe7bb8de673ac07570539e68e3R82),
but I'm not sure if it's right, so would be nice to have your eyes on it.
To validate simply export multiple templates from the same flow
with/without changes and execute 'diff’ on it. You should only see what was
changed.
I’ll be adding few tests as well.
> Export templates in a deterministic way
> ---------------------------------------
>
> Key: NIFI-826
> URL: https://issues.apache.org/jira/browse/NIFI-826
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Reporter: Matt Gilman
> Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
>
> Templates should be exported in a deterministic way so that they can be
> compared or diff'ed with another. Items to consider...
> - The ordering of components
> - The id's used to identify the components
> - Consider excluding irrelevant items. When components are imported some
> settings are ignored (run state).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
