feat: add custom marshmallow validation#1438
Conversation
… parameters, sampling, and prediction intervals
…loading and error handling
…poser requirements
…ased loading and error handling
…on with schema validation and error handling
… handling in PipelineRunConfig
|
All PEP8 errors has been fixed, thanks ❤️ Comment last updated at Thu, 25 Jun 2026 13:52:40 |
|
/fix-pep8 |
…d ensemble config, and sampling configuration
…nd composer requirements
…module and updating imports
… for improved validation
… update import paths
… validation and update import paths
…dation and update import paths
…aths for improved parameter validation
…ion and update import paths
…idation functions
…atios in sampling configuration
…data, and pipelines
…data tests for improved error handling
|
|
||
| top_level_field = field_path.split('.')[0] | ||
| default_value = get_field_default(schema, top_level_field) | ||
| if default_value is None: |
There was a problem hiding this comment.
What if None is default?
There was a problem hiding this comment.
great question.
maybe it's time to revise all defaults and instead of allowing None as a default value, we could suggest an alternative, such as a custom FedotNone type.
please note that this PR is just a draft for implementing a robust validation layer, not the final solution – use it if it suits your needs in your specific tasks
There was a problem hiding this comment.
FedotNone is a good solution, I think.
|
Is it correct to be able to replace incorrectly set values with default values? |
|
Now the user can work both through the API and directly through TD_Creator. In this case, where should the source of truth for parameter validation be located — at the API level, at the TD_Creator level, or in the common schema/validation function that both layers use? I want to avoid duplication of rules, but at the same time maintain correct validation for both usage methods. |
the ultimate source of validation lies in marshmallow schemas. |
yes, with |
|
/fix-pep8 |
3 participants
Summary
Context