Github user mcgilman commented on the issue:
https://github.com/apache/nifi/pull/1306
@ijokarumawak Yes, your understanding here is correct. Sorry, I was missing
what's unique about this case which is that it is an **optional** number. I
don't believe we have this case elsewhere. Other places where we have numbers,
they have default values and support being updated but not unconfigured.
I have one thought that may make the DTO/API a little more clear. As is,
the behavior of setting the fields differ within the same DTO and even amongst
the same fields depending on the presence of other fields. Since we want the
batch settings to be treated as a single unit in terms of configuration, what
are your thoughts introducing a `BatchSettingsDTO` for relaying this
configuration? For clarity, I'm suggesting the possibility of the
`RemoteProcessGroupPortDTO` having a `BatchSettingsDTO` which has `batchCount`,
`batchSize`, and `batchDuration`.
With this approach, in the `RemoteProcessGroupPortDTO` the behavior is
consistent. If a field is set, attempt to configure it. If a field is null,
leave the existing configuration in place. Within the `BatchSettingsDTO` we can
stipulate that these fields are a single unit and the proposed configuration
will replace the existing configuration. I think this approach would be
functionally equivalent but may be slightly less confusing.
Thoughts?
Not trying to be super picky here but need to be very conscious of the
changes as they are part of the public REST API. Just trying to make this as
clear as possible. If someone directly invokes these endpoints I'd hate if they
inadvertently cleared the existing desired configuration.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
