Draft: Replacing dataclass with Pydantic

Pull Request Template

Title: Replacing dataclass with Pydantic

Description:

Replacing dataclass with Pydantic offers several advantages:

• Validation: Pydantic provides automatic data validation, ensuring that the values of the fields meet specific types and constraints (e.g., integer ranges, string length). This is particularly useful when working with data from untrusted sources or APIs, as it ensures data integrity.
• Data Parsing: Pydantic makes it easy to parse and convert data, especially when working with complex structures like JSON. With Pydantic, it is easy to convert input data into Python objects, and vice versa, with minimal code and supporting special characters
• Type Checking: While dataclasses are limited to basic Python type annotations, Pydantic extends this functionality with runtime type checking, providing deeper integration with static analysis tools and type hinting.
• Enhanced Performance: Pydantic is optimized for performance, especially in scenarios involving complex or deeply nested data models. It uses efficient methods for validation and serialization, making it more suitable for larger datasets or high-performance applications.
• Serialization Support: Pydantic provides built-in methods for easily serializing and deserializing data to and from formats like JSON
• Error Handling: Pydantic offers detailed error messages and allows for easy customization of validation logic, which helps improve debugging and understanding of data issues.

---

Changes Introduced

• Dataclass has been replace by pydantic object wihtout changing the developer API
• use get_model method instead of get_dataclass(deprecated in 2.0)
• Fixes #1
• Fixes #2

---

Related Issues

• Fixes #3

---

Definition of Done

The following criteria must be met before this PR can be considered as "Done":

• version number has been updated.
• Code changes are fully implemented and functional.
• Unit tests have been created or updated to cover the changes.
• User manual has been updated and can be generated by a task on the gitlab-ci
• Test plan has been updated and can be generated by a task on the gitlab-ci
• Test report can be generated by a task on the gitlab-ci
• Documentation (e.g., user manual, test plan, test results) can be published on the web by a task on the gitlab-ci
• The feature or bug fix has been tested on a clean environment.
• All related configuration files have been updated (e.g., Dockerfile, CI/CD pipeline).

---

Testing

(Explain how the changes can be tested. Provide any steps or commands required for testing the PR locally.)

---

Is this ready for review?

• Yes
• No