Use validation library for model input validation

[fkromer]

The need for validation functions could be avoided if we'd define model classes as models using generic library support. These days the most common alternative for this purpose is pydantic. pydantic enables:

• definition of domain models
• type based model schema validation
• validation via built-int field constraints
• advanced validation via Validators and Validation Decorators

This would result in a rather bigger refactoring. Pls let me know what you think about this proposal @izar . I'd like to avoid the preparation of PRs which would not be accepted.

[izar]

Moving to pydantic is in the roadmap, yes.

[fkromer]

Support for serialization could potentially be helpful (to resolve #268 ?) as well.

[raphaelahrens]

The blocker for #268 is #273 since the sql dump code does not really make any sense to me and I don't know how this should be resolved.
The JSON serialization works.

Regarding the move to pydantic, I think it is a good decision.
But this would also require some form of packaging of pytm for different OSes.
Until now pytm had no dependencies besides python (except for the sqldump feature).
When using pydantic this would of course change.

[colesmj]

Regarding the move to pydantic, I think it is a good decision. But this would also require some form of packaging of pytm for different OSes. Until now pytm had no dependencies besides python (except for the sqldump feature). When using pydantic this would of course change.

Agreed pydantic would be the preferred choice - var-based enum-ing is very cumbersome now - although would introduce some dependency challenges as you highlight. But the benefit of readability and flexibility (especially if you want to do some fancy object customizations) may be significant to outweigh the challenge. Unlike the sql dependency checking to optionally enable the feature, this change for pydantic would be all or nothing (and a breaking change?).
Pydantic would not be the only Rust-based dependency in pytm (depending on outcomes of other PRs).

[fkromer]

@raphaelahrens

The blocker for #268 is #273 since the sql dump code does not really make any sense to me and I don't know how this should be resolved.

I agree. If relationships are dropped the sqldump is useless and I‘m pretty sure no one uses the feature. It would be valid to question the need of the feature then. @izar What is the use case for sql dumps. If the purpose would be data output for data analyzation purposes there are better alternatives available nowadays. https://github.com/duckdb/duckdb is an efficient embedded analytics database for example. Output using https://parquet.apache.org/ files could be even simpler cause there would not be a dependency on a server running. This would simplify testing as well.

[fkromer]

@raphaelahrens

But this would also require some form of packaging of pytm for different OSes.
Until now pytm had no dependencies besides python (except for the sqldump feature).
When using pydantic this would of course change.

pytm is already packaged https://pypi.org/project/pytm/ and has python package dependencies

pytm/pyproject.toml

Line 8 in da8a2c6

[tool.poetry.dependencies]

Personally I’m not using the pypi package due to the dependencies pytm has on non-python dependencies which cannot be packaged into a python package. Most users will use either Docker or devbox for dependency isolation pretty sure.

[fkromer]

@colesmj

Unlike the sql dependency checking to optionally enable the feature, this change for pydantic would be all or nothing (and a breaking change?).

In the worst case the introduction would be a breaking change and would imply that users need to upgrade custom libraries used to extend pytm functionality. One way to handle this issue is to introduce the pydantic improvements into pytm v2.0.0 and keep maintaining the > v1.3.1 in parallel. pytm side the least effort would be to provide bug and security fixes only for > v1.3.1. More kind would be to consider new features in >= v2.0.0 and > 1.3.1 to give pytm users more time to migrate their custom libraries.

I don’t know the pytm internals good enough TBH. pydantic models are classes which can be inherited from. If custom, pre-pydantic model classes inheriting from pydantic models break I don’t know. This topic deserves some investigation before deciding if to provide pydantic based models as part of > v1.3.1 or >= v2.0.0

[fkromer]

@colesmj

Pydantic would not be the only Rust-based dependency in pytm (depending on outcomes of other PRs).

As long as pytm does not use Rust extensions itself Rust does not need to be considered at all. Python packages making use of Rust are provided as compiled binaries usually. Those packages can be used as any Python-only packages.

[raphaelahrens]

@raphaelahrens

The blocker for #268 is #273 since the sql dump code does not really make any sense to me and I don't know how this should be resolved.

I agree. If relationships are dropped the sqldump is useless and I‘m pretty sure no one uses the feature. It would be valid to question the need of the feature then. @izar What is the use case for sql dumps. If the purpose would be data output for data analyzation purposes there are better alternatives available nowadays. https://github.com/duckdb/duckdb is an efficient embedded analytics database for example. Output using https://parquet.apache.org/ files could be even simpler cause there would not be a dependency on a server running. This would simplify testing as well.

It is very difficult to say how many people use this, and it was implemented so it must have had a use case.
But maybe this should be a new issue, where this should be discussed.

[izar]

The sqldump implementation was for my own use, and I don't think others are using it, seeing as it is currently broken and nobody has complained. I have no issues with modernizing it with a better solution.

…

On Mon, Oct 20, 2025, 02:41 Raphael Ahrens ***@***.***> wrote: *raphaelahrens* left a comment (OWASP/pytm#295) <#295 (comment)> @raphaelahrens <https://github.com/raphaelahrens> The blocker for #268 <#268> is #273 <#273> since the sql dump code does not really make any sense to me and I don't know how this should be resolved. I agree. If relationships are dropped the sqldump is useless and I‘m pretty sure no one uses the feature. It would be valid to question the need of the feature then. @izar <https://github.com/izar> What is the use case for sql dumps. If the purpose would be data output for data analyzation purposes there are better alternatives available nowadays. https://github.com/duckdb/duckdb is an efficient embedded analytics database for example. Output using https://parquet.apache.org/ files could be even simpler cause there would not be a dependency on a server running. This would simplify testing as well. It is very difficult to say how many people use this, and it was implemented so it must have had a use case. But maybe this should be a new issue, where this should be discussed. — Reply to this email directly, view it on GitHub <#295 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC2BAPQYCABP63RCVFO4AL3YR7ZTAVCNFSM6AAAAACJCMP7F6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMRQG43DKNRUGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>