#23 #26 Improve error handling for relation macros

[tovganesh]

Restructure relation macros to better handle errors, improving consistency of getting the relation types.

Description of the issue can be found in #23 and #26

Test plan:
The test cases are available in GH Issue #23 and Issue #26

[sdairs]

This seems to have improved things for #23 but not completely eliminated it - it is able to recover from a failure on a subsequent run, which it couldn't before.

I do still see drop table if exists dbt_demo_staging_covid.stg_covid__cases__dbt_backup being run on view materialisations.

Perhaps we should investigate a more reliable way of determining the entity type of a model?

[tovganesh]

This seems to have improved things for #23 but not completely eliminated it - it is able to recover from a failure on a subsequent run, which it couldn't before.

I do still see drop table if exists dbt_demo_staging_covid.stg_covid__cases__dbt_backup being run on view materialisations.

Perhaps we should investigate a more reliable way of determining the entity type of a model?

Right - the "drop table" is created because the get_relation_type macro defaults to return 'table' if the object is not found. May be the execution of drop shouldn't happen at all if the object is not found.

I have now added a tweak - which should take the relation type correctly.

I did try using jinja dbt functions - but wasn't able to get required info.

Were you able to also test this for #26 ?

[raghotham]

LGTM