Create central pydantic models #11827
Conversation
|
|
||
|
|
||
| class HDADetailed(HDASummary): | ||
| model_class: str = ModelClassField(HDA_MODEL_CLASS_NAME) |
There was a problem hiding this comment.
It's really awesome to see this all in one place, it makes the duplicated and/or expensive fields very visible.
| title="Miscellaneous Blurb", | ||
| description="TODO", | ||
| ) | ||
| file_ext: str = Field( # Is this a duplicate of HDASummary.extension? |
| title="Metadata Files", | ||
| description="Collection of metadata files associated with this dataset.", | ||
| ) | ||
| data_type: str = Field( |
There was a problem hiding this comment.
This is kind of a duplicate of ext ... ext maps to a data_type. Maybe we should deprecate this at some later point ?
Returning the actual class is also not very stable, this is probably something that should have never left the API
| title="Display Applications", | ||
| description="Contains new-style display app urls.", | ||
| ) | ||
| display_types: List[DisplayApp] = Field( |
There was a problem hiding this comment.
I would love to deprecate this AND display_apps AND visualizations... this is dictated by the data type and can be mapped that way on the client.
There was a problem hiding this comment.
I thought this too but it looks like there is a filter when I was looking over #11880 which filters by dbkey.
There was a problem hiding this comment.
:( that is unfortunate. We might still be able to do it on the client (and there would be great value in it, this can be the bulk of data transferred in the details view), but that is a good bit more fiddly then.
| const=True, | ||
| title="HDA or LDDA", | ||
| description="Whether this dataset belongs to a history (HDA) or a library (LDDA).", | ||
| deprecated=False # TODO Should this field be deprecated in favor of model_class? |
There was a problem hiding this comment.
Using just one of them is probably a good idea
davelopez
force-pushed
the
central_pydantic_models
branch
from
d69448c to
67c3fdc
Compare
|
This PR adds nearly 70 pydantic models so far. I placed all the models in |
davelopez
changed the title
The ModelClassField can be reused to declare the common property model_class field in pydantic models
These models correspond with the different serialization views of HDAs.
davelopez
force-pushed
the
central_pydantic_models
branch
from
b1cfcaf to
a301adb
Compare
|
This is excellent, that so much @davelopez! |
|
Thank you @mvdbeek! |
The idea is to build some of the 'central' pydantic models for HDAs, HDCAs, Jobs, etc., and provide annotations and field documentation for them.
I've tried to make a bit of research (or at least some grepping) to write a description for each field but it was a bit difficult sometimes to figure out so I've put a
TODOin those cases. Please feel free to directly suggest a description in the review if you know how to describe the field or improve any of the existing :)I've also marked some fields as
deprecated(initially usingFalse) when I feel, by the code comments around, that the model field was supporting some legacy functionality.What did you do?
UserModelfromlib/galaxy/managers/users.pytolib/galaxy/schema/schema.pywhoamiAPI endpoint to return the user encoded ID(*) Those changes were originally addressed in #11315 but that PR will probably take some time to be merged so I've included them here.
Why did you make this change?
As part of the efforts to move to FastAPI, creating, annotating, and documenting the pydantic models is one of the most time-consuming/tedious tasks, but an important one if we want to provide decent documentation in OpenAPI. Also, providing the models early will speed up the migration of API routes in the long term.
How to test the changes?
(This will be tested automatically when the models are used in the API tests as they will get serialized/deserialized.)
License