Hi, my thanks to the Datahub team for providing th...
# ui
b
Hi, my thanks to the Datahub team for providing this software as opensource to the community. I am evaluating this product for my company's use. Using the quick start, I ingested some metadata in json using the rest API and then edited the description of some fields in the dataset. I then looked at the records in MySQL and saw that there were 2 records, EditableSchemaMetadata and SchemaMetadata. I then updated the SchemaMetadata by running a slightly edited version of the original json. I noticed that the UI edits stayed untouched. Does the frontend-UI always prioritize showing UI edits in the EditableSchemaMetadata over that of SchemaMetadata?
g
Hello! Welcome to the community. Your observation is correct- for now the UI always prioritizes edited descriptions. If you click the edit icon next to the description you are able to see both the most recent edited and non edited description side by side.
m
@better-orange-49102: in your use-case, what is the behavior you would want to see?
b
Thanks for replying! I'm wondering if there is value in showing both the latest version of SchemaMetadata and EditableSchemaMetadata along with a timestamp, so that users would know the recency of information. For instance, a user might have just edited the description in UI a few days back, but perhaps ingest have just pulled in a different schema for the dataset an hour ago. The current implementation still works for me - I can just overwrite the latest EditableSchemaMetadata with another EditableSchemaMetadata through the rest API. Out of curiosity, is there any implementation of rollback of edits or approving of changes in Linkedin's internal implementation? For instance, someone who accidentally made changes to the UI. In the absence of admin roles in datahub, im thinking of setting up a separate service with access to the previous records in MySQL so that people can "resubmit" those rows. It is a hacky solution, but I do not really want to touch the Datahub source code unless I absolutely have to.
m
@better-orange-49102 thanks for the suggestions.
In LinkedIn's internal impl: we have some safeguards around certain metadata edits by locking it to just the owners
b
I see, thanks for sharing!
m
We are working on RBAC this quarter in the oss DataHub, which should address your issue of preventing edits from non allowed people
❤️ 1
In the example you described of "re-ingesting" schema metadata... in the case where the schema field's description did not change, it seems like we should continue to use the human edited version of the documentation.
so timestamp by itself may not be enough?
b
that's true. it's not foolproof