[dagster-looker] Use Looker API translator instance in spec loader and state-backed defs

[maximearmstrong]

Summary & Motivation

Same as #26734 but for Looker.

How I Tested These Changes

BK

Changelog

[dagster-looker] load_looker_asset_specs and build_looker_pdt_assets_definitions are updated to accept an instance of DagsterLookerApiTranslator or custom subclass.

[maximearmstrong]

• [dagster-looker] Update Looker docs to use translator instance and LookerApiTranslatorStructureData #26744
• [dagster-looker] Use Looker API translator instance in spec loader and state-backed defs #26743 👈 (View in Graphite)
• [dagster-looker] Move contextual data from DagsterLookerApiTranslator to LookerApiTranslatorStructureData #26742
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

Deploy preview for dagster-docs ready!

Preview available at https://dagster-docs-e2vj8ud0g-elementl.vercel.app
https://maxime-use-translator-instance-in-load-looker-asset-specs.dagster.dagster-docs.io

Direct link to changed pages:

• https://dagster-docs-e2vj8ud0g-elementl.vercel.app
  https://maxime-use-translator-instance-in-load-looker-asset-specs.dagster.dagster-docs.io/integrations/looker

[OwenKephart]

Because this is a breaking change, we'd need to wait for dagster 1.10 in order to merge this.

I think the better option here is to make the type Union[DagsterLookerApiTranslator, Type[DagsterLookerApiTranslator]], and emit a deprecation warning if a Type is passed in

Edit: looks like a lot of the related PRs also have breaking changes, so maybe the plan was already to just wait for 1.10 to merge them all, is that right?

[maximearmstrong]

Because this is a breaking change, we'd need to wait for dagster 1.10 in order to merge this.

I think the better option here is to make the type Union[DagsterLookerApiTranslator, Type[DagsterLookerApiTranslator]], and emit a deprecation warning if a Type is passed in

Edit: looks like a lot of the related PRs also have breaking changes, so maybe the plan was already to just wait for 1.10 to merge them all, is that right?

Spec loaders and asset factories for BI integrations, like load_looker_asset_specs and build_looker_pdt_assets_definitions here, are all marked as experimental, so I believe we can go ahead with these changes?

q

[schrockn]

It wouldn't be that hard to do what @OwenKephart suggested right?

Even though we are "allowed" to do breaking changes if a relatively low effort option is available we should do that, especially on a feature we have discussed so publicly.

[maximearmstrong]

It wouldn't be that hard to do what @OwenKephart suggested right?

Even though we are "allowed" to do breaking changes if a relatively low effort option is available we should do that, especially on a feature we have discussed so publicly.

That makes sense - I thought avoiding a deprecation cycle for an experimental feature would have been the best, but I see the value in emitting the warning. I can go ahead and make the update.

[schrockn]

Would like a test to test the deprecation warning (on the power BI one as well) but will not block

[maximearmstrong]

Would like a test to test the deprecation warning (on the power BI one as well) but will not block

Updated for Power BI, Tableau and Looker