Closed utkarsharma2 closed 1 year ago
Patch coverage: 64.06
% and project coverage change: +0.11
:tada:
Comparison is base (
5a81abb
) 66.51% compared to head (1be7369
) 66.62%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
@sunank200 Addressed your concern, please take a look.
Description
What is the current behavior?
Currently, for transfer_params we have a logic to convert dict to TransferIntegrationOptions but that doesn't seem to be executed. Due to this, we are essentially using dict type in our codebase assuming it's of type TransferIntegrationOptions. Which seems to mess with static type check.
closes: https://github.com/astronomer/apache-airflow-provider-transfers/issues/51
What is the new behavior?
We need to use the TransferIntegrationOptions class or its subclass internally, so any dict that is passed to transfer_params should be converted to TransferIntegrationOptions or a subclass.
Algorithm:
TransferIntegrationOptions
or subclass of it. We let it pass, assuming the user knows what he is doing.dict
, convert it to an Option class, We check if the transfer mode is third-party,Ingestor
class comes fromconn_id
passed intransfer_param
. Once we get theIngestor
class we look for theOPTIONS_CLASS
attribute, this attribute is supposed to hold a reference to correctOptions Class
TransferIntegrationOptions
and instantiate it with dict.provider
ofdestination_dataset
. we determineprovider
class byconn_id
ofdestination_dataset
. Once we have theprovider
class, we look forOPTIONS_CLASS
attribute, this attribute is supposed to hold a reference to correctOPTIONS_CLASS
OPTIONS_CLASS
Attribute found - We use dict to instantiate this class.OPTIONS_CLASS
Attribute not found - We use the classTransferIntegrationOptions
and instantiate it with dict.Does this introduce a breaking change?
Nope
Checklist