-
Notifications
You must be signed in to change notification settings - Fork 328
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
Proposal: Update DatasetVersion versioning #2071
Comments
What's the reasoning behind steps 2 and 3? I can see the usefulness of the |
In my opinion, the
Each dataset will have its |
@collado-mike @wslulciuc Is there anything additional I need to do to bring this to a vote or anything like that? |
Sorry for the radio silence here, Ryan. Please open a PR with the proposal and we can approve it. |
There has been some discussion (mostly in #1977) about reworking the versioning system for
DatasetVersion
.Motivation
The current
DatasetVersion
versioning system leads to confusion (e.g. #1883).DatasetVersion
has auuid
field (of typeUUID
) and aversion
field (also of typeUUID
). In a practical sense, I think these fields are redundant.Additionally, external data systems might already support dataset versioning (e.g. delta, iceberg). It'd make sense for Marquez to support these.
Proposal
I propose that a
Version
'suuid
field should assume the functionality currently provided byVersion
'sversion
field, and add an additional fieldexternal_version
to support dataset versions provided by external applications. This would have a downstream impact onJobVersion
.Work required
String
DatasetVersion
'sversion
fieldDatasetVersion
:external_version
(String
)JobVersion
'sversion
fieldJobVersion
:external_version
(String
).DatasetVersionDatasetFacet
facet to support external dataset versions.dv.uuid
instead ofdv.version
)If this proposal is accepted, I'll open an official proposal.
The text was updated successfully, but these errors were encountered: