David/Pierre,
Thank you for the prompt and thoughtful replies.
Reset Support/Semantics
I think lock/reset support could be considered and I would agree that
might shift the naming semantics. My original intent is that immutable
would be you set once and the connector would need to be recreated to
change. I feel what is proposed fits nicely with the definition of
immutable "unable to be changed, altered, or modified over time". If we
want to consider allowing this to be reset I would modify my proposal to
call this ConnectorPropertyDescriptor lockable as David suggests.
.lockable(boolean isLockable)
From there we could document that setting lock to true would implicitly
mean it is locked if the connector ever reaches the RUNNING stage. Then
unlock could be considered a connector action to reset the lock. The
semantics in the ConnectorNode persistence could be changed then to
contain a list of locked properties (say lockedConnectorProperties ) on
the ConnectorNode which could be added and removed individually or in
bulk by API/Action.
The idea of allowing a lock to apply to different stages is interesting
but I would be hesitant to introduce that concept in the initial go.
For example what phases, currently represented by the ConnectorState
enum would we support? Perhaps "UPDATED" might be a good fit. Then
then api could be enhance to accept a list of ConnectorStates that would
trigger the lock.
.lockable(boolean isLockable, List<ConnectorState> triggerState)
Then we would need the persistence of the lockedConnectorProperties to
be updated when the connector state transitioned. So the current design
could evolve to either of these. However the other states are
transitional and don't seem to provide a lot of meeting over the life of
the connector (DRAINING, PURGING, TROUBLESHOOTING). So at this point I
think this might be too early for such a concept and we'd want to defer
that decision to later based on usage. Like what should TROUBLESHOOTING
state do? Should that implicitly unlock? I'm not sure I have a good
understanding of the usecases to tackle that question yet.
I'm open to both suggestions but both are a bit beyond my original
intent as immutable means just that it is set once and never changed.
Although just going through this though experiment on locking leads me
to believe that the persistence proposed in the NIP should change
regardless to list out properties that are now set as immutable rather
than simply tracking hasBeenStarted on the ConnectorNode. But if we
want these additional features (lock/reset) then I would agree lets
tweak the semantics as mentioned above.
Sincerely,
Bob
On 7/23/2026 11:16 AM, David Handermann wrote:
Bob,
Thanks for initiating the discussion. Based on Pierre's comment, and
considering the general notion of Connector Properties, it would be
helpful to consider the naming semantics a bit more.
Immutable strongly connotes inability to change, whereas it seems the
more specific goal is to support a set-once strategy. Rather than
immutable, perhaps something more along the lines of a Property Status
would be helpful. The status could be LOCKED or UNLOCKED as a way to
communicate whether it could be changed. Those may not be the best
semantic names, so I'm open to ideas.
Another approach might be something like indicating the phase or stage
at which a property can be configured. Such as initialization versus
any.
The core concept certainly sounds useful, so I'm in favor of the goal,
but would like to see some iteration on the particulars before final
approval.
Regards,
David Handermann
On Thu, Jul 23, 2026 at 10:26 AM Pierre Villard
<[email protected]> wrote:
Hi Bob, thanks for the proposal.
I definitely do see the value of making sure some properties cannot be
changed after the connector starts. I guess that with this change we
would be saying that the connector has to be deleted and recreated to
make a configuration change for such properties. I imagine that in the
future we may want to expose a way to "reset" the connector so that it
does not need to be deleted. And, in this case, the connector could
have some code to take the appropriate actions in such a scenario.
Definitely a +1 for the NIP.
Thanks,
Pierre
Le jeu. 23 juil. 2026 à 14:56, Bob Paulin <[email protected]> a écrit :
Hi,
I'd like to raise a proposal to add an immutable option to
ConnectorPropertyDescriptor. I've included details in a JIRA [1] for
review by the community. If the proposal is of interest to the PMC I'd
like to request a sponsor per [2] since I am neither PMC or a committer
on the project. Thank you for your consideration!
Sincerely,
Bob Paulin
[1] https://issues.apache.org/jira/browse/NIP-36
[2]
https://cwiki.apache.org/confluence/spaces/NIFI/pages/318606579/NiFi+Improvement+Proposal+Process
