Feat!: Add support for virtual statements to be executed post update

[themisvaltinos]

This update introduces statements that are executed after a virtual update. These can be used for example to grant privileges on views of the virtual layer.

These expressions should be defined within a ON_VIRTUAL_UPDATE_BEGIN; ...; ON_VIRTUAL_UPDATE_END; block. For example:

MODEL (
  name db.customers 
);

SELECT 
  item_id
FROM 
  db.seed_model;

ON_VIRTUAL_UPDATE_BEGIN; 

GRANT SELECT ON VIEW @this_model TO ROLE role_name;

INJA_STATEMENT_BEGIN;     
GRANT REFERENCES, SELECT ON FUTURE VIEWS IN DATABASE {{ db }} TO ROLE owner_name;  
JINJA_END;  

ON_VIRTUAL_UPDATE_END;

Jinja expressions are also supported within this block by properly nesting the Jinja block as shown in the example above.

In these statements table resolution occurs at the virtual level, meaning that qualified view names (including @this_model) are used instead of the physical table names. For example, when running the plan in an environment named dev, the db.customers as well as this_model would resolve to db__dev.customers rather than the physical table.

For python models these statements are defined in the @model decorator:

@model( 
  "db.customers",  
  on_virtual_update=["GRANT SELECT ON VIEW @this_model TO ROLE role_name;"]
)

[izeigerman]

Can we please make sure this feature is documented before we merge.

[izeigerman]

Let's not call private methods here. What you had previously (render_on_virtual_update) was great.

[izeigerman]

Also I don't think kwargs contains anything meaningful here. This is mostly for future expansions, since this interface is public. No need to pass in into renderer I don't think

[themisvaltinos]

Right changing it to use a public method instead similar to pre/post statements

Regarding the kwargs I am passing the table mapping of qualified view names, which is then propagated down to render and used here:

sqlmesh/sqlmesh/core/renderer.py

Line 382 in c1d117e

table_mapping=table_mapping,

so it is needed to resolve model names to their corresponding view names of the current environment, so I'm not sure without passing them how I could do this