-
Notifications
You must be signed in to change notification settings - Fork 15
Making data local should be a workflow step #287
Comments
I fully agree. |
Poff! |
I'd like to see this in version 1.0 as this is how Cate should make datasets local in the future. It will also further simplify and clarify data access API, CLI and GUI. |
Local data source:
|
Remember to keep (or at least recognize) the |
Remember the requirements for the data source ID:
|
To be discussed: allow local datasets to grow in time. |
For ID my suggestion is to combine local prefix, remote name, constrains hash local.esacci.GHG.satellite-orbit-frequency.L2.CH4.multi-sensor.multi-platform.VARIOUS.ch4_v1-0.r1.78685637-a631-3eaa-993e-969fa6134da2 And any human-readable description keep in Title. |
Made this a |
Expected behavior
The operation
open_dataset
should be extended by aforce_local: bool = False
option and alocal_ds_id: str = None
.If
force_local == True
andds_id
refers to a remote data source, thenlocal_ds_id
is either given or will be set to a new ID which is made up of theds_id
and any given constraints.local_ds_id
already exists and is valid, then it will be openedlocal_ds_id
does not yet exist, it will be created by downloading the remote data, then the local version will be openedIf
force_local == False
the behavior is as it is now.The new desired behavior is that we want to make the data access part of a workflow so the enclosing workspace can be shared and can run anywhere, regardless of the current state of the user's local data store.
Actual behavior
Local data source must be created before any workflow is created. If a workflow step's
open_dataset
operation then refers to such a local data source, it cannot be shared without telling how the local data source was named, which remote ID was used, and which constraints have been used to create it.Specifications
Cate 0.9.0dev3
The text was updated successfully, but these errors were encountered: