[
https://issues.apache.org/jira/browse/NIP-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18092971#comment-18092971
]
Kevin Doran commented on NIP-34:
--------------------------------
Thanks for the write-up. I'm supportive of this API enhancement
> Add migrateProperties API to Connector
> --------------------------------------
>
> Key: NIP-34
> URL: https://issues.apache.org/jira/browse/NIP-34
> Project: NiFi Improvement Proposal
> Issue Type: Improvement
> Reporter: Bob Paulin
> Priority: Major
>
> h2. Motivation
> {{Processor}} and {{ControllerService}} expose
> {{migrateProperties(PropertyConfiguration)}} so an extension can rename,
> remove, or re-shape its property descriptors over time without breaking flows
> that were persisted under the old shape. The framework invokes that hook
> whenever a component is restored from disk or imported from a flow definition.
> The {{Connector}} extension point from NIP-11 has no equivalent. Connector
> configuration is persisted in {{flow.json}} keyed by
> {{ConfigurationStep.getName()}} and
> {{{}ConnectorPropertyDescriptor.getName(){}}}, so any renamed descriptor,
> removed property, or renamed step silently drops user configuration on the
> next restart. This proposal gives Connectors parity with the Processor /
> Controller Service migration hook.
> h2. Scope
> {{nifi-api}} additions only:
> * New interface
> {{{}org.apache.nifi.migration.ConnectorPropertyConfiguration{}}}.
> * New interface
> {{{}org.apache.nifi.migration.ConnectorStepPropertyConfiguration{}}}.
> * New default no-op method
> {{migrateProperties(ConnectorPropertyConfiguration)}} on
> {{{}org.apache.nifi.components.connector.Connector{}}}.
> Out of scope: cross-flow migration via
> {{{}MigratableConnector.migrateConfiguration{}}}, which is a separate concern.
> h2. Description
> {{Connector.migrateProperties(ConnectorPropertyConfiguration)}} is invoked
> whenever a Connector is restored from a persisted configuration. The default
> implementation is a no-op.
> {{ConnectorPropertyConfiguration}} operates across configuration steps:
> {{{}getStepNames{}}}, {{{}hasStep{}}}, {{renameStep(old, new)}} (re-keys the
> entire step preserving every property and value reference; rejects
> destination collisions), {{{}removeStep{}}}, and {{forStep(stepName)}} which
> returns a per-step sub-view. The sub-view is registered the first time a
> property is written.
> {{ConnectorStepPropertyConfiguration}} mirrors
> {{org.apache.nifi.migration.PropertyConfiguration}} minus
> {{{}createControllerService{}}}, and adds typed value-reference operations to
> align with {{{}ConnectorMigrationContext.setValueReference(...){}}}. It
> exposes {{{}renameProperty{}}}, {{{}removeProperty{}}}, {{{}hasProperty{}}},
> {{{}isPropertySet{}}}, {{setProperty(String)}} for string literals,
> {{setValueReference(ConnectorValueReference)}} for typed sets (and removal
> when {{{}null{}}}), {{getPropertyValue}} (literal-string view),
> {{getValueReference}} (typed view), and {{getProperties}} /
> {{{}getValueReferences{}}}. Default overloads accept
> {{{}ConnectorPropertyDescriptor{}}}. All rename operations preserve the
> underlying {{ConnectorValueReference}} subtype, so {{SecretReference}} and
> {{AssetReference}} values survive a rename without conversion.
> Together these primitives cover common evolution cases: adding, removing, or
> renaming a property; moving a property across steps; and adding, removing, or
> renaming an entire {{ConfigurationStep}} with its properties intact. The
> framework invokes the hook from
> {{StandardConnectorNode.inheritConfiguration(...)}} for both the active and
> working configuration on every restart and flow import, then drives the
> existing per-step {{setConfiguration(..., force=true)}} callbacks from the
> post-migration map. Migrated names are persisted on the next {{flow.json}}
> save, similar to how Processor and Controller Service migration propagates
> today.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
