tpalfy commented on PR #10538: URL: https://github.com/apache/nifi/pull/10538#issuecomment-3723938271
@exceptionfactory Can you please provide some objective reasoning for considering the ConsumerPartitionsUtil too complex? Here are my objective reasoning to argue against it: 1. 210 rows. Not a big class by any measure. 2. 4 public methods and 4 private methods. This is not out of the ordinary for any util class. 3. Only java.net and java.util imports, apart from org.apache.nifi.components.ValidationResult and org.apache.nifi.logging.ComponentLog. The logic in it is exceptionally well contained. 4. In NiFi 1.x the same class had 1 change since it's inception in 2020, and that was about logging. The class is exceptionally stable and isolated. 5. I found only 2 changes related to static partition mapping in the old code. The logic implemented in this PR _intentionally_ follows that implementation for the very reason to minimize risk. Also there's an obvious contradiction in adding a separate processor. Code duplication would mean that basically all the changes done to ConsumeKafka would need to be carried over to the new class. Now _that_ would be a maintenance nightmare. According to the original Jira https://issues.apache.org/jira/browse/NIFI-11259, it was agreed upon that full compatibility will be achieved by adding this feature later. There is a Jira (still open) that proves this:https://issues.apache.org/jira/browse/NIFI-13654 That is also an objective fact. Here's the implementation as agreed upon, following the original as closely as possible, which was proven to be working and stable by the previous change history. Can't see how we can get better than that. Unless more adequate reasons are provided to deny this change, this should move forward. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
