minor: load_partitions for hive metastore loaders #694
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Solving #690
Description
This pull request adds
Load_partitions
boolean switch to the Metastore creation form forHMSMetastoreLoader
andHMSThriftMetastoreLoader
.Solution
I've noticed that this switch is already available in
GlueDataCatalogLoader
, so I've decided to extract the form field to a new module and reuse it from there in all three loaders.Backwards compatibility
If I just tried to change the form and opened a Metastore page that uses
HMSMetastoreLoader
, the front-end returned following error:[Immer] Immer only supports setting array indices and the 'length' property
caused by an array of URLs still present in the DB for the loader inmetastore_params
field.HMSMetastoreLoader
loader that changesmetastore_params
into proper dictionary in data migrations.If there is an existing metastore that uses
HMSMetastoreLoader
orHMSThriftMetastoreLoader
, it has a behavior of loading all partitions right now. After applying changes from this pull requests,Load_partitions
would be turned off by default."load_partitions": True
inmetastore_params
for these two loaders in data migrations.Another solution would be to create completely new loader classes (
HMSMetastoreLoaderV2
,HMSThriftMetastoreLoaderV2
) that would not infer with the current DB data. But this approach could lead to big number of very similar loaders after some time, so I wasn't sure about it.