Update SQL server relations to not require an alias#604
Conversation
set dbt_sqlserver_disable_empty_relation_aliases default to True keep SQL Server relation _render_limited_alias() hook for no-alias behavior update empty-mode fixture SQL to use explicit user aliases so default no-alias behavior is valid preserve opt-in flag path/test for user validation
|
@Benjamin-Knight Please merge if ready, they reverted to true this for some reason for v1.10 microsoft/dbt-fabric@4aca77d |
|
I'll double check this statement they have in the pull request for 1.10. Updated the require_alias attribute in FabricRelation to True, aligning with dbt-core 1.10.0 requirements. I do not remember seeing that requirement but will ensure that is the case. |
Please let me know if we can include the workaround on v1.10 so feature is usable without having to analyze the implications of the require_alias change, we could find another solution or wait for the bug to be resolved upstream somehow dbt-labs/dbt-adapters#199. |
|
I can't see any reason for that statement in the fabric code, the flag you've setup allows for it to be swapped depending on how the user wants the adapter to work. Its important because right now the adapter requires that you either never use an alias or always use an alias to use these features. That's fine but right now without the toggle its enforces that you never use an alias, and sometimes that isn't possible when your projects get more complex. The only question is whether we should have the default be the current behaviour, which is that it does generate an alias and the flag should opt into the new behaviour so that this isn't a breaking change. |
Lets start without changing that so we can test on production and follow up the upstream issue, they could introduce changes or features that depends on having that setup so opt-in is safer right now |
2 participants
Closes #595
Any project that uses the empty flag and expect the adapter to set aliases would find it no longer works.