AIP-65: Update dag source endpoint to support versioning #43492
Conversation
boring-cyborg
bot
added
area:API
ephraimbuddy
force-pushed
the
version-api
branch
2 times, most recently
from
bb2a352
to
3ec23a2
Compare
ephraimbuddy
force-pushed
the
version-api
branch
from
3ec23a2
to
c157489
Compare
ephraimbuddy
changed the title
ephraimbuddy
requested review from
bbovenzi,
pierrejeambrun,
ryanahamilton,
jscheffl,
ashb and
XD-DENG
as code owners
ephraimbuddy
added
the
legacy api
ephraimbuddy
force-pushed
the
version-api
branch
from
c157489
to
8fce1aa
Compare
airflow/models/dag_version.py
Outdated
| @@ -136,7 +136,8 @@ def get_latest_version(cls, dag_id: str, *, session: Session = NEW_SESSION) -> D | |||
| def get_version( | |||
| cls, | |||
| dag_id: str, | |||
| version_number: int = 1, | |||
| version_number: int | None = None, | |||
| version_name: str | None = None, | |||
There was a problem hiding this comment.
@jedcunningham, I remember we removed the version_name, but this seems necessary when using the API & UI to look up the code version. Let me know what you think.
There was a problem hiding this comment.
I think it should either require it to be singular get_version(version_number), or plural get_versions(version_name). As proposed, getting the latest version for get_version(version_name) feels like a weird interface to me.
There was a problem hiding this comment.
From the UI perspective, how should users search for DAG version? Should it be dag_id and number only?
There was a problem hiding this comment.
What's the difference between the version number and name? Is one better for display and another better for querying?
There was a problem hiding this comment.
The version number is incremented each time there's a structural change to the DAG, while the version name does not change. You can have all the DAGs with the same version name. I think for display, having version_name-version_number would be good. However, I'm wondering if we really need the version_name @jedcunningham.
There was a problem hiding this comment.
version_name is just a way for authors to add something that is meaningful for them. Strictly speaking we could do away with it completely.
There was a problem hiding this comment.
From the UI perspective, how should users search for DAG version?
I'm not sure we really want users searching by DAG version, but it'd be more informational.
If we did, however, I think letting folks go by either would be fine. But it would be in the context of "dag runs for version x", moreso than searching for versions directly. None of that is planned at the moment afaik though.
There was a problem hiding this comment.
I have removed the version_name altogether.
ephraimbuddy
force-pushed
the
version-api
branch
2 times, most recently
from
a541914
to
ef8cce6
Compare
ephraimbuddy
force-pushed
the
version-api
branch
2 times, most recently
from
611f8df
to
9a2705b
Compare
Enhanced the DAG source endpoint to support version-based retrieval Refactored the get_dag_source function to allow fetching specific versions of DAG source code using dag_id, version_name, and version_number parameters. Replaced file_token with dag_id in endpoint paths and removed unnecessary token-based access. Updated OpenAPI specifications and requested serializers to include new versioning parameters. Modified API response schema to include dag_id, version_name, and version_number for improved version tracking. Added/updated tests
ephraimbuddy
force-pushed
the
version-api
branch
from
9a2705b
to
41107bc
Compare
Enhanced the DAG source endpoint to support version-based retrieval
Refactored the get_dag_source function to allow fetching specific versions of DAG source code using dag_id, version_name, and version_number parameters.
Replaced file_token with dag_id in endpoint paths and removed unnecessary token-based access.
Updated OpenAPI specifications and requested serializers to include new versioning parameters.
Modified API response schema to include dag_id, version_name, and version_number for improved version tracking.
Added/updated tests