Repository navigation
move model.bom.Bom.validate() to validation.models #455
Description
Activity
- linked a pull request that will close this issue[IDEA] refactor: model validator #456
on Sep 26, 2023 - changed the title
[-][IDEA] move `model.bom.Bom.validate()` to `validation.models`[/-][+]move `model.bom.Bom.validate()` to `validation.models`[/+]on Sep 16, 2024 This is just moving
Bom.validate()tovalidation.modelas-is and update the references, or do you want it refactored into smaller functions?This is just moving
Bom.validate()tovalidation.modelas-is and update the references, or do you want it refactored into smaller functions?existing public API shall be deprecated and something more advanced shall be provided.
details may be discussedOpened a draft to get something going on.
I've implemented a ModelValidator that returns an iterable of errors (so you can collect multiple issues instead of failing on the first one). It's side-effect free - just validates, doesn't mutate anything.
@jkowalleck I noticed Bom.validate() was marked "deprecated without replacement," but it does two things - normalization (
register_dependency calls) AND validation. For backward compatibility, I kept both in the deprecated method. The new ModelValidator only validates. How do you want to handle this going forward?- Keep the current approach (normalization stays in deprecated Bom.validate())
- Remove it completely (breaking change) and make validation optional with a parameter
Do you already have some ideas about advance impelementation?
- Schema-based
- Multi-mode (strict, unstrict)
- Severity level
- linked a pull request that will close this issuefeat!: implement ModelValidator and remove Bom.validate() #935
on Apr 30, 2026
now that a package
validationwas established via #432,t should be possible to move the data model validation there, too.\
data model validation is getting more and more complex #453
and should be encapsulated and could be devided.