[
https://issues.apache.org/jira/browse/MINIFI-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616462#comment-15616462
]
ASF GitHub Bot commented on MINIFI-117:
---------------------------------------
Github user JPercivall commented on a diff in the pull request:
https://github.com/apache/nifi-minifi/pull/45#discussion_r85604460
--- Diff:
minifi-toolkit/minifi-toolkit-configuration/src/main/java/org/apache/nifi/minifi/toolkit/configuration/ConfigMain.java
---
@@ -336,6 +329,16 @@ public int transform(String[] args) {
return SUCCESS;
}
+ protected void validateAndPrintIssues(ConfigSchema configSchema) {
+ if (!configSchema.isValid()) {
+ System.out.println("There are validation errors with the
template, still outputting YAML but it will need to be edited.");
+
configSchema.getValidationIssues().forEach(System.out::println);
--- End diff --
Yup the first print is correct (was just including it to show what is wrong
with the config). The print out for the upgrade could be more user friendly
something like:
`
There were validation errors prior to upgrading:
<just the specified version errors>
After upgrading it has these validation errors:
<any errors after upgrading>
Any validation errors after upgrading will need to be addressed prior to
using the config.
`
In its current state it looks like the upgraded template has validation
errors for both destination ids and destination name (which should be mutually
exclusive).
> Maintainable Configuration Versioning
> -------------------------------------
>
> Key: MINIFI-117
> URL: https://issues.apache.org/jira/browse/MINIFI-117
> Project: Apache NiFi MiNiFi
> Issue Type: Bug
> Reporter: Bryan Rosander
> Assignee: Bryan Rosander
>
> In order to avoid a tangled web of if/else statements around every possible
> permutation of config.yml and an equally complicated validation routine, we
> need to utilize a versioning strategy that allows for specific parsing and
> validation code for each version of the ConfigSchema.
> This will allow us to determine if a schema will be compatible with an older
> MiNiFi instance more easily by validating the structure of the file at a
> given version while still supporting an upconvert on read to the latest
> ConfigSchema while parsing at runtime.
> It should also facilitate a deprecation strategy of removing older versions'
> classes without needing to touch current implementation
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
