<https://github.com/linkedin/datahub/pull/2855> ^ ...
# ui
s
https://github.com/linkedin/datahub/pull/2855 ^ is every single change going to be a new version. Or is it something like hashicorp's vault where we can choose to add a new version with changes to multiple properties?
g
Hey @square-activity-64562 - each change is going to create a new version as of today.
How would you want to have the versions broken down? Would you want to manually set the scope of each aggregate "version"? Or write rules about what constitutes a "version change" and what doesn't?
s
I am just worried that it will create too many versions for this versioning to be useful in case of large number of columns. Say I have a table with more than 50 columns. If I go and add notes for each of them I will have 50+ versions depending on how much I edit. That will quickly become hard to use. Hashicorp vault's versioning is a solution that comes to mind. They have a edit button which allows to edit all properties at once and then do a publish to publish a new version. These versions don't have any timestamps either so it is hard to know when the change was made. But that is a separate UX issue.
g
This history is currently just for changes to the schema that come from ingestion- primarily focused on showing when the schema changes when columns were added, updated or removed. Viewing history of editing descriptions is a slightly different problem, and I agree it needs a different solution
There, it might make more sense to view the history of a single column's description at a time, this would help cut out the noise that you point out!
s
That makes sense
b
So to summarize, version history is not based on comments / descriptions of individual schema fields added in the DataHub UI. It's based on changes to the metadata stored in this model, which mainly includes columns, their types, etc.
b
i checked the hosted demo at https://demo.datahubproject.io/, 1. is version history meant to show changes in editableMetadataSchema or MetadataSchema? Are there any plans to extend this to other aspects? 2. Either way, showing the timestamps for the versions would be helpful to help orient the viewer. especially for those who are not aware that version 0 is the latest and version X is the 2nd latest. 2. for bigquery or s3, the version history button does not show up. it only appears for snowflake.
s
version 0 is the latest and version X is the 2nd latest
If this is true this is confusing numbering
b
https://datahubproject.io/docs/advanced/aspect-versioning/#solution-version-0 it was mentioned here. so the largest version no is the 2nd newest version
s
It might be better to rename the current version as latest or current instead and change that dropdown so that it is in reverse order.
Copy code
latest
version 5
version 4
version 3
...
version 1
Currently the UI is misleading as it showing order as
Copy code
version 0
version 1
..
This might lead people to incorrectly believe that numbering starts from 0 here. Showing timestamp of change is definitely a plus. But the current UI also needs to be changed or there will be a lot of confusion from users.
b
Agree!
@green-football-43791 For feedback on this feature 🙂
g
Hey @square-activity-64562! Thanks for the feedback! I agree that renaming the latest version would be helpful, and we will reverse the order the versions appear in the dropdown.