[
https://issues.apache.org/jira/browse/MINIFI-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15596059#comment-15596059
]
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_r84528235
--- Diff:
minifi-commons/minifi-commons-schema/src/main/java/org/apache/nifi/minifi/commons/schema/serialization/SchemaLoader.java
---
@@ -30,13 +32,13 @@
import java.util.stream.Collectors;
public class SchemaLoader {
- private static final Map<String, Function<Map, ConfigSchema>>
configSchemaFactories = initConfigSchemaFactories();
+ private static final Map<String, Function<Map,
ConvertableSchema<ConfigSchema>>> configSchemaFactories =
initConfigSchemaFactories();
- private static Map<String, Function<Map, ConfigSchema>>
initConfigSchemaFactories() {
- Map<String, Function<Map, ConfigSchema>> result = new HashMap<>();
- result.put(String.valueOf((Object)null), ConfigSchema::new);
- result.put("", ConfigSchema::new);
- result.put("1", ConfigSchema::new);
--- End diff --
The changes in the Config schemas need to be documented. Could you add a
section to the admin guide (the Config Schema portion) that explains the
versioning scheme as well as what changed in v2?
I am suggesting to put it in the docs instead of a migration guidance for a
release because working with multiple different version of MiNiFi and configs
will be an everyday task (esp when C&C is added).
> 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)
