Skip to content
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

AIP-84 Migrate GET Dag Runs endpoint to FastAPI #43506

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

rawwar
Copy link
Collaborator

@rawwar rawwar commented Oct 30, 2024

related to #42701

@boring-cyborg boring-cyborg bot added area:API Airflow's REST/HTTP API area:UI Related to UI/UX. For Frontend Developers. labels Oct 30, 2024
),
],
session: Annotated[Session, Depends(get_session)],
# fields: list[str] | None = Query(None),
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pierrejeambrun, @bugraoz93 , looking for ideas on how to implement fields to return.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Due to its type and purpose, this should be similar to update_mask (even though it is reversed regarding masking). We will get in explode=true, similar to update_mask again ....?fields=item1&fields=item2.

As far as I see there isn't a way to exclude fields during validation and doing dump and validate won't work until we have a dynamically generated Pydantic model with the selected fields making the validation on return. I saw a discussion about including this capability. There are also some workarounds for people there. Maybe we can also have a generic exclusion method for Pydantic models until it is provided fully.
pydantic/pydantic#9573

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now you can just skip fields. Because it's an issue to implement and dynamically change the returned type. (sub fields etc...), which isn't great for the client.

This is mentioned here #43378 (comment), as one of the breaking change.

We can either fix that later before 3.0 release, or accept that breaking change. In the mean time I would suggest to just remove it and don't bother with it.

@pierrejeambrun pierrejeambrun added the legacy api Whether legacy API changes should be allowed in PR label Nov 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:API Airflow's REST/HTTP API area:UI Related to UI/UX. For Frontend Developers. legacy api Whether legacy API changes should be allowed in PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants