At the moment when a class is missing in the schema registry, the validation doesn't automatically fail. Instead the data passes through unchanged and a warning is written. This was introduced as a temporary solution to be able to make the changes for the schema registry in separate PRs and has some problems.
It works well if the configuration is not nested, but for nested cases it can be that a dictionary passes through unchanged and then the validation fails at the next step because it tries to validate against a parent class which doesn't contain all the fields of the subclass. And unfortunately it is from the error message not entirely easy to understand that it happens because the subclass is missing in the registry.
There are two options for how to solve this:
-
Keep the behaviour and try to figure out some work around. For example, maybe better error reporting.
-
Conclude that now when all the PRs have been merged, validation should actually fail at the first step if a schema is not registered. No data which has a class/class_path/type field should be allowed to pass through unchanged but instead an error should be raised to say that the class is missing.
I think option 2 feels like the most appropriate behaviour now because otherwise you can turn validation on and believe that your configuration is validated despite that in reality not all parts are. However, making this change means that validation=False will be needed until both pyaml-cs-oa and tango-pyaml also been updated otherwise it is not possible to validate configurations which include controls fields.
Still, it's probably not a major problem at the moment. At the moment the dynamic validation is on by default which means that even if you use validation=False validation will be done at the point when the factory creates the objects. We can wait to add #328 until validation=True works including the control bindings.
At the moment when a class is missing in the schema registry, the validation doesn't automatically fail. Instead the data passes through unchanged and a warning is written. This was introduced as a temporary solution to be able to make the changes for the schema registry in separate PRs and has some problems.
It works well if the configuration is not nested, but for nested cases it can be that a dictionary passes through unchanged and then the validation fails at the next step because it tries to validate against a parent class which doesn't contain all the fields of the subclass. And unfortunately it is from the error message not entirely easy to understand that it happens because the subclass is missing in the registry.
There are two options for how to solve this:
Keep the behaviour and try to figure out some work around. For example, maybe better error reporting.
Conclude that now when all the PRs have been merged, validation should actually fail at the first step if a schema is not registered. No data which has a class/class_path/type field should be allowed to pass through unchanged but instead an error should be raised to say that the class is missing.
I think option 2 feels like the most appropriate behaviour now because otherwise you can turn validation on and believe that your configuration is validated despite that in reality not all parts are. However, making this change means that
validation=Falsewill be needed until bothpyaml-cs-oaandtango-pyamlalso been updated otherwise it is not possible to validate configurations which include controls fields.Still, it's probably not a major problem at the moment. At the moment the dynamic validation is on by default which means that even if you use
validation=Falsevalidation will be done at the point when the factory creates the objects. We can wait to add #328 untilvalidation=Trueworks including the control bindings.