Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dagster-powerbi] Move contextual data from DagsterPowerBITranslator to PowerBITranslatorData #26654

Conversation

maximearmstrong
Copy link
Contributor

@maximearmstrong maximearmstrong commented Dec 20, 2024

Summary & Motivation

This PR implements PowerBITranslatorData, a container class containing a PowerBIContentData object (props) and a PowerBIWorkspaceData object (context), to pass contextual data to the translator without breaking the get_asset_spec signature or requiring context to be passed to the __init__ method of the DagsterPowerBITranslator.

This is PR is an alternative to the proposals mentioned in #26617.

How I Tested These Changes

Updated tests with BK

Changelog

[dagster-powerbi] Type hints in the signature of DagsterPowerBITranslator.get_asset_spec have been updated - the parameter data is now of type PowerBITranslatorData instead of PowerBIContentData. Custom Power BI translators should be updated.

Copy link
Member

Is this every going to cause a recursive explosion of data?

I guess we are relying on the fact that PowerBIWorkspaceData will only ever hold references to PowerBIContentData rather than PowerBITranslatorData.

That's kind of why I was imagining a container class that holds a reference

class PowerBITranslatorData:
   content: PowerBIContentData
   workspace: PowerBIWorkspaceData

As it would make the possibility structurally impossible via the type system.

Overall this looks good though.

@maximearmstrong maximearmstrong force-pushed the maxime/move-translator-context-to-translator-props-class-powerbi branch from cb21360 to 9ab65c3 Compare December 26, 2024 19:49
Copy link

github-actions bot commented Dec 26, 2024

Deploy preview for dagster-docs ready!

Preview available at https://dagster-docs-1mngnv18l-elementl.vercel.app
https://maxime-move-translator-context-to-translator-props-class-powerb.dagster.dagster-docs.io

Direct link to changed pages:

@maximearmstrong
Copy link
Contributor Author

maximearmstrong commented Dec 26, 2024

@schrockn in theory, it's not a problem because PowerBIWorkspaceData is expected to be created with PowerBIContentData objects and not PowerBITranslatorData objects.

Currently, DagsterPowerBITranslator.get_asset_spec takes a PowerBIContentData object - Making PowerBITranslatorData a subclass of PowerBIContentData avoid breaking the signature.

That said, after thinking about this, we should not subclass PowerBIContentData for 2 reasons:

  • To make sure we avoid the recursion explosion of data, we would need some type checks in PowerBIWorkspaceData, which is kinda awkward
  • Adding these type checks is an anti-pattern and breaks the Liskov substitution principle in Python - instances of a subclass can be passed where instances of a class are expected without causing any problems.

I updated this PR to make PowerBITranslatorData a container class, and updated the signature of DagsterPowerBITranslator.get_asset_spec so that the data param is of type PowerBITranslatorData.

Here's why I think we can move forward with this approach:

  • After testing previous custom translators, this change does not raise an exception
  • Only type checkers like Pyright will fail with this change, if users are using one and if they use type hints in their custom translator. Note: the code doesn't break with this change, only type hints in the signature of DagsterPowerBITranslator.get_asset_spec.
  • The translator classes for BI integrations are not marked as experimental, but every callsite is (spec loader, asset def builder, etc.). Adding a changelog in this PR to state that the type hints in the signature of DagsterPowerBITranslator.get_asset_spec changed seems reasonable enough to warn users.

@@ -78,6 +78,23 @@ class PowerBIContentData:
properties: Dict[str, Any]


class PowerBITranslatorData(NamedTuple):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can just make this @record but not serializable to be consistent with the rest of this interface.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 7c63440

Copy link
Member

@schrockn schrockn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Container class works for me!

Copy link
Member

@schrockn schrockn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @maximearmstrong I think one thing we could do here to make the transition a little easier would be to implement the properties of PowerBIContentData on PowerBITranslatorData. That way the code wouldn't break, just the the typehints.

Meaning

class PowerBITranslatorData:
    
   @property
   def content_type(self) -> PowerBIContentType:
      return self.content_data.content_type

@maximearmstrong
Copy link
Contributor Author

Hey @maximearmstrong I think one thing we could do here to make the transition a little easier would be to implement the properties of PowerBIContentData on PowerBITranslatorData. That way the code wouldn't break, just the the typehints.

@schrockn Exactly - that's the current state of this PR.

The changes requested here were already implemented in bb5b904 when we switched to using a container class.

Only type checkers like Pyright will fail with this change, if users are using one and if they use type hints in their custom translator

I will update this part of this comment to emphasize that code does not break in the current state.

@@ -21,7 +21,7 @@ class CustomDagsterPowerBITranslator(DagsterPowerBITranslator):
def get_report_spec(self, data: PowerBIContentData) -> dg.AssetSpec:
return (
super()
.get_report_spec(data)
.get_report_spec(data) # type: ignore
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why new type: ignore?

Copy link
Contributor

@dpeng817 dpeng817 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good, let's see if we can get rid of the type ignore in the docs snippet

@maximearmstrong maximearmstrong force-pushed the maxime/move-translator-context-to-translator-props-class-powerbi branch from 88115b1 to 24fe471 Compare January 2, 2025 18:27
Copy link
Member

@schrockn schrockn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please update PR summary to be accurate (still refers to subclassing)

@maximearmstrong maximearmstrong merged commit 05d029a into master Jan 2, 2025
2 checks passed
@maximearmstrong maximearmstrong deleted the maxime/move-translator-context-to-translator-props-class-powerbi branch January 2, 2025 19:51
maximearmstrong added a commit that referenced this pull request Jan 2, 2025
…to TableauTranslatorData (#26739)

## Summary & Motivation

Same as #26654 but for Tableau.

## How I Tested These Changes

Updated tests with BK

## Changelog

[dagster-tableau] Type hints in the signature of
`DagsterTableauTranslator.get_asset_spec` have been updated - the
parameter `data` is now of type `TableauTranslatorData` instead of
`TableauContentData`. Custom Tableau translators should be updated.
maximearmstrong added a commit that referenced this pull request Jan 2, 2025
… to LookerApiTranslatorStructureData (#26742)

## Summary & Motivation

Same as #26654 but for Looker.

## How I Tested These Changes

Updated tests with BK

## Changelog

[dagster-looker] Type hints in the signature of
`DagsterLookerApiTranslator.get_asset_spec` have been updated - the
parameter `looker_structure` is now of type
`LookerApiTranslatorStructureData` instead of `LookerStructureData`.
Custom Looker API translators should be updated.
maximearmstrong added a commit that referenced this pull request Jan 3, 2025
…ontainer classes (#26798)

## Summary & Motivation

Same as #26654 but for Sigma.

## How I Tested These Changes

Updated tests with BK

## Changelog

[dagster-sigma] Type hints in the signature of
`DagsterLookerApiTranslator.get_asset_spec` have been updated - the
parameter `data` is now of type `Union[SigmaDatasetTranslatorData,
SigmaWorkbookTranslatorData]` instead of `Union[SigmaDataset,
SigmaWorkbook]`. Custom Looker API translators should be updated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants