-
Notifications
You must be signed in to change notification settings - Fork 3
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
disallowed extra fields in models, and updated ingest and export code to handle these #127
Conversation
|
||
|
||
def filter_model_dictionary(dictionary: dict, target_model: Type[BaseModel]): |
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 wonder whether this has utility beyond just the export code, and would be better off as a utils in the shared_models package. Thoughts?
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.
- Are you referring to
persist
orfilter_model_dictionary
- Do you mean 'import code' in comment above? It seems both
import
andexport
usepersist
- So having it in a common place sounds good. However, I assumeexport
is only reading data models so will not need the filter functionality (but will need the persisting).
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.
-
filter_model_dictionary
-
i meant import. But the export could use it with slightly different data models (e.g. the study model for export is the study model + dataset model + biosample, protocols, Image Acquisitions etc.) so having a filter model dictionary method might be helpful.
-
For persist - While both might want to write out to files, it feels like the directory/file structure might be very different for the export and ingest code, so i don't know how reusable the methods would be. Additionally, the functions related to filtering models makes sense to store in the model package since it's related and is going to be imported by both, but it's less obvious where we should put the persisting.
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.
filter_model_dictionary looks good, I wouldn't know about how it fits with the rest of the code though
|
||
|
||
def filter_model_dictionary(dictionary: dict, target_model: Type[BaseModel]): |
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.
Nice workaround for the filter!
return protocol | ||
|
||
|
||
def get_test_specimen_growth_protocol() -> List[bia_data_model.ImageAcquisition]: |
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.
This whole method was just a duplicate, so i removed it.
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
See: https://app.clickup.com/t/86956q84r
Also updated website export code to use input that are at least as complex as the BIA data models (i.e. with the various api fields), since it will make using the clients easier.