[
https://issues.apache.org/jira/browse/NIFIREG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16351518#comment-16351518
]
Kevin Doran commented on NIFIREG-136:
-------------------------------------
I think we should definitely consider this, especially since we already enforce
the requirement of unique bucket names and unique flow names within a bucket
(correct?). My biggest concern would be that the human readable names are, by
design, changeable, so URLs based of bucket/item names would change. So to
introduce this safely for those that need/want immutable URIs (e.g., used in an
automation task that should not fail simply because someone renames a flow), we
would need a way to support permalinks as well.
> Switch to unique human-friendly names for buckets and flows
> -----------------------------------------------------------
>
> Key: NIFIREG-136
> URL: https://issues.apache.org/jira/browse/NIFIREG-136
> Project: NiFi Registry
> Issue Type: Improvement
> Affects Versions: 0.1.0
> Reporter: Andrew Grande
> Priority: Major
>
> I have been playing with the Registry and using [~bende] 's early CLI to
> accomplish some automation tasks. Have had really tough times with UUIDs
> being used for buckets and flows, it introduced a lot of context switches to
> locate/save/copy/paste those when using the API.
> I would strongly suggest considering the human-friendly names and convert
> deep links to using those instead. This not only provides for an easy
> portable full URI, but also addresses compatibility issues between instances
> of the registry, as buckets & flows with the same name are guaranteed to have
> different UUIDs. A kind of copy/paste between environments.
> I never came across a unique name requirement within a tree-like structure to
> be an issue when dealing with NiFi. E.g. NiFi and NiFi Registry could
> transparently reverse-look up the UUID by extracting names from the URI. The
> goal is to have a great user experience.
> P.S.: spaces in the name in the URI could be substituted for '+' sign
> transparently, using the %20 would defeat the purpose of smooth ease-of-use.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
