-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat 45 missing fields #46
Conversation
src/aind_slims_api/models/base.py
Outdated
@@ -77,5 +76,17 @@ def _serialize(self, field, info): | |||
else: | |||
return field | |||
|
|||
def model_dump(self, serialize_quantity=True, *args, **kwargs) -> Dict[str, Any]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might not be a good idea to override pydantic methods. Is there a different way to handle this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could make it a custom method instead -- something like "custom_model_dump"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, actually I have new thoughts on this. The gymnastics are necessary because we have a special serialization need for quantities when posting to SLIMS, implemented with the _serialize method. However, we also want to be able to serialize naturally into a python dict with reasonable values, but the departure from the norm is due to slims, so whatever we do, the normal behavior should be default and the weird behavior should be different.
All that to say, here's the three options I see:
- Change the validator to accept a quantity as a dict
- add a model_dump_slims method (analogous to pydantic's model_dump_json) that does the weird serialization.
- Add context to the serializer so the client can call
.model_dump(context='slims_post')
and get the quantity dict, but a normal**model
will remain the types you expect.
I like 3 the best, but we could also do 2 and 3 together to add clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3 seems reasonable. We are going to ask Slims to provide a plugin to let us just query their sql db tables directly. I feel like we are having to resort to too many of these "gymnastics" to just get data from their backend. It might almost be more efficient to just use the requests
module directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Less gymnastics seems better. I think the main goal of this library is to just isolate the ways people get and put data into SLIMS so that people are using versioned code (that can be improved and tracked with issues, etc) rather than passing around requests snippets. It would be really helpful if it was easier to use but I think the Session, Mouse interfaces are a huge improvement in the right direction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Logging will be better to configure instead of using print statements.
closes #45
This PR: