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

Add a dictionary of links to AvailabilityState. #1214

Merged
merged 1 commit into from
Oct 25, 2024
Merged

Add a dictionary of links to AvailabilityState. #1214

merged 1 commit into from
Oct 25, 2024

Conversation

agorajek
Copy link
Member

Summary

This feature allows to integrate our AvailabilityStates with external tools, such as data visualizations. For example... when a new availability state is added or updated, we can submit additional urls that can be shown on the Materialization tab of the node.

This PR adds:

  • the API call to save the additional links information,
  • the adjustment to the UI to show the links together with the Materialized Datasets

Example:
Screenshot 2024-10-24 at 10 55 16 AM

Test Plan

  • PR has an associated issue: #
  • make check passes
  • make test shows 100% unit test coverage

Deployment Plan

Copy link

netlify bot commented Oct 24, 2024

Deploy Preview for thriving-cassata-78ae72 canceled.

Name Link
🔨 Latest commit cdcd5c9
🔍 Latest deploy log https://app.netlify.com/sites/thriving-cassata-78ae72/deploys/671be4d1cad1400008cfffbc

Copy link
Contributor

@samredai samredai left a comment

Choose a reason for hiding this comment

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

This is awesome and is going to really unlock the seamless end to end dev flow we've been working towards. Huge thanks @agorajek. One thing I was wondering is if we should expect cases where someone wants to add links but not necessarily attach it to the materialization for a node. For example if a metric node has a doc that might be useful to link out to. I think it's enough to suggest they just put it in the metric description but just wanted to get your thoughts on that.

Copy link
Contributor

@shangyian shangyian left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for adding this!

@@ -31,6 +31,7 @@ class AvailabilityState(Base): # pylint: disable=too-few-public-methods
table: Mapped[str]
valid_through_ts: Mapped[int] = mapped_column(sa.BigInteger())
url: Mapped[Optional[str]]
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we can actually remove url now, since that was just a single link, but with this change we'll have the option for multiple, and all named as well. Although there will be a database migration involved if we do remove.

Copy link
Member Author

@agorajek agorajek Oct 25, 2024

Choose a reason for hiding this comment

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

I was thinking about it. And I noticed that the top level url attribute is typically used as a link to a canonical catalog for a particular dataset, which makes sense to be separate. But then it should be called catalog_url so maybe I should just rename it, if you agree with this idea?

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually dataset_url sounds more intuitive than catalog_url. What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll skip this for now.

@agorajek
Copy link
Member Author

This is awesome and is going to really unlock the seamless end to end dev flow we've been working towards. Huge thanks @agorajek. One thing I was wondering is if we should expect cases where someone wants to add links but not necessarily attach it to the materialization for a node. For example if a metric node has a doc that might be useful to link out to. I think it's enough to suggest they just put it in the metric description but just wanted to get your thoughts on that.

I think we will want to have "links" in various places. This one is specific to the Availability State / MaterializedDataset, hence I added it on that entity. In the case of other links I think we should place them as close to the proper entity as possible. Because metric nodes (an all nodes) have a description that's a good place to add a doc link, but I can see having a generic links field on the nodes as well. This way the integrations with other tools are easier to pull off.

@agorajek agorajek merged commit 4b68b40 into main Oct 25, 2024
16 checks passed
@agorajek agorajek deleted the DJ-41 branch October 25, 2024 23:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants