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.userid, customers.customername and transactions.orderdate will cascade to the new view. Any tags on customers.userid will not cascade.
- Tags applied at the table level do not cascade. For example, if one dataset is tagged status:approved and the other is not, the resulting joined view does not have the status:approved tag on it.
- If the view lineage is not present. See View Lineage.

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.

Warning

Dropping a dataset (table or view), and recreating it, removes its view lineage.