Add the ability to unmarshal RawState. #42
Merged
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.

The tfprotov5.RawState type exposes state through a []byte containing
JSON when upgrading resource state with the UpgradeResourceState RPC. We
had not surfaced any JSON parsing or decoding in the exported API, so
providers would need to parse the JSON themselves.
To solve this, we use the same Unmarshal interface we use for parsing
JSON from DynamicValues, letting users receive a tftypes.Value from a
RawState without needing to worry about encoding... mostly.
There is one hitch. The Flatmap syntax doesn't have a canonical
translation (yet? As far as I know) to Terraform's type system. So we
sidestep that by returning an error, for the moment. In the future, we
could conceivably institute a mapping, though I'm not convinced it's a
good idea to, given the number of assumptions that would need to be
made. It is a larger undertaking to do that in a predictable, reliable
way. Provider developers should provide their own mapping of Flatmap to
tftypes.Value.
The Flatmap property should only ever be populated in one specific
scenario, as best I can tell:
the last version of Terraform to write the state file.
At that point, the plugin-go-based provider would be the first version
of the provider to write the state after 0.12, meaning it would be its
responsibility to upgrade the state between the flatmap syntax and
Terraform's type system.
It is unknown how likely that scenario is, but I want to document it
here to avoid any confusion.