Understanding Tag Inheritance¶
By default any tag assignment or removal operations on a parent database or dataset cascades down to its descendant views. This includes assigning tags at the database level, dataset level, and column level. After creating new views, tags on the parent dataset are inherited by the newly created view.
There are some cases where tags do not cascade (are not inherited):
If the view transforms the parent in any way (such as aggregations, column data manipulation, etc), none of its tags cascade.
For views with joins:
Okera cascades tags only on directly referenced columns. For example:
CREATE VIEW sales.orders_by_customer AS SELECT transactions.userid, customers.customername, transactions.orderdate FROM sales.transactions INNER JOIN sales.customers ON transactions.userid=customers.userid;
Only tags on columns
transactions.orderdatewill cascade to the new view. Any tags on
customers.useridwill not cascade.
Tags applied at the table level do not cascade. For example, if one dataset is tagged
status:approvedand the other is not, the resulting joined view does not have the
status:approvedtag on it.
If the view lineage is not present. See View Lineage.
To cascade tags, Okera maintains the view lineage as part of a dataset's metadata to determine where the tag inheritance originated. This can be viewed in the UI.
Tags only cascade if the view lineage is present. View lineage is only available for views created using Okera versions after 2.1. If Okera is connected to an external metastore, and views were created directly inside that metastore, bypassing Okera, they do not show view lineage. Similarly, any views created through Okera prior to the Okera 2.1 release do not have a view lineage. It may be necessary to recreate these views if you want tags to cascade on them.
Dropping a dataset (table or view), and recreating it, removes its view lineage.