Open ocefpaf opened 3 weeks ago
@callumrollo this is something I wanted to do for a long time but only got to it after your tutorial yesterday.
The PR is not ready yet b/c we need to think about the possible corner cases. Also, setting a griddap dataset_id is slow now b/c griddap_initialize
is always called. I'm not sure if there is a better option b/c we allow users to re-call it, making checking if those properties are already defined would prevent re-running... Or we can make a breaking change and throw away re-running griddap_initialize
and assume that, if self.constraints
, self.dim_names
, and self.variables
, calling griddap_initialize
won't change them.
Nice! I think calling griddap_initialize
in the background when a user sets dataset_id
when the server was set up with protocol=griddap
is a great idea. I don't think the delay is significant enough to be annoying.
I would recommend against throwing away the user available griddap_initialize
method though. As a user I sometimes do something like:
e = ERDDAP(y) e.dataset_id = x e.griddap_initialise (no longer need this, nice!) e.variables = a,b,c e.constraints = {} # some breaking changes e.to_xarray() # fails due to the breaking changes I made e.griddap_initialize() # reset the constraints to something that works again
I thought about renaming it to griddap_reset
or re_initialize
but that would be a breaking change. We will keep it and document that one should use it only to "reset the query params."
Right now we need this extra step for
griddap
but we can skip it run that automatically every time adataset_id
is set.