You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The pydantic models for the new API are currently defined in the kernelci-api. In other parts of the project (pipeline and helpers/libs in kernelci-core) there are ad-hoc implementations of data checkers and sanitizers that could be replaced by the proper use of pydantic model validators, but in order to do that they'd need to be in a place that's accessible by all the project components.
This was already discussed in past conversations, the consensus is that there are some bits of the api that could be refactored into kernelci-core and then imported by either kernelci-api or kernelci-pipeline as needed. This would reduce code duplication and future maintenance problems.
The text was updated successfully, but these errors were encountered:
Yes, and also it's important to make it clear that only the models that are used in the client-facing API endpoints should be defined in the kernelci common package. The API implementation can have its own set of internal models for the data stored in the database (that's already the case with users).
The pydantic models for the new API are currently defined in the kernelci-api. In other parts of the project (pipeline and helpers/libs in kernelci-core) there are ad-hoc implementations of data checkers and sanitizers that could be replaced by the proper use of pydantic model validators, but in order to do that they'd need to be in a place that's accessible by all the project components.
This was already discussed in past conversations, the consensus is that there are some bits of the api that could be refactored into kernelci-core and then imported by either kernelci-api or kernelci-pipeline as needed. This would reduce code duplication and future maintenance problems.
The text was updated successfully, but these errors were encountered: