Closed russellshackleford closed 5 years ago
In the case that the runtime does not provide a cached value, the provider needs to figure out the current state (if that is relevant to its operations) by itself. You can have a look at the code handling that in SimpleProvider
:
Thanks for the reply. So I'm reading this as: if the resource isn't already cached, then get
itself needs to be called manually from within set
and harvest just the bits relevant to name
. Can you please confirm this? Thanks!
What exactly needs to happen is entirely up to the implementer of the provider. There is no requirement to call the get
function.
For example, the provider could be talking to an API that is itself idempotent, and never needs to know the current state. In this case the set
method would not have to do any additional work if is
is missing.
Alternatively, if the provider is using a third-party library to manage the resources, it might be more economical to directly call out into that library instead of going through get
again.
Finally, if your usecase is very simple, inheriting from the SimpleProvider
and only implementing get
, create
, update
, and delete
would completely avoid that for you.
Thanks for the clarification!
Clear enough. The resource isn't there and needs to run through
create
I'm not sure what this is supposed to mean. Does this mean it doesn't show up as a resource but that the resource might actually be there? If that's the case, I don't know what
set
is supposed to do about it. Can someone please clarify? Thanks!