Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an attr.Convert helper. #120

Merged
merged 4 commits into from
Sep 14, 2021
Merged

Add an attr.Convert helper. #120

merged 4 commits into from
Sep 14, 2021

Conversation

paddycarver
Copy link
Contributor

This function converts an attr.Value to use a new attr.Type, so long
as they share a compatible tftypes.Type representation. This allows
code that doesn't know the type of an attr.Value to still use it,
provided they know the kind of data it holds.

For example, a validation helper that works on strings--MaxStringLength,
say--could look something like this:

// assume req.Config is an attr.Value
strAttr, err := attr.Convert(ctx, req.Config, types.StringType)
if err != nil {
  panic(err)
}
var str types.String
diags := tfsdk.ValueAs(ctx, strAttr, &str)
if diags.HasError() {
  panic("oops")
}
// do something with `str`, which is now strongly typed

Then no matter what attr.Type provider devs use in their schema, this
validator would still work, then. Without the conversion step, it
wouldn't work, as tfsdk.ValueAs implementation needs to know the
attr.Type of the attr.Value, and reusable validators can't know
that. So the point of this helper is to get an attr.Value into a known
attr.Type format.

This still needs tests.

@paddycarver
Copy link
Contributor Author

Depends on #119.

@paddycarver paddycarver force-pushed the paddy_attr_convert branch 2 times, most recently from b936f57 to 2faf1c2 Compare September 8, 2021 12:06
@paddycarver paddycarver marked this pull request as ready for review September 8, 2021 12:06
@paddycarver paddycarver requested a review from a team September 8, 2021 12:06
@paddycarver
Copy link
Contributor Author

Still depends on #119, but has tests and is otherwise code complete.

@paddycarver paddycarver force-pushed the paddy_attr_convert branch 2 times, most recently from 15a059c to 322ff86 Compare September 8, 2021 15:15
This function converts an `attr.Value` to use a new `attr.Type`, so long
as they share a compatible `tftypes.Type` representation. This allows
code that doesn't know the type of an `attr.Value` to still use it,
provided they know the kind of data it holds.

For example, a validation helper that works on strings--MaxStringLength,
say--could look something like this:

```
// assume req.Config is an attr.Value
strAttr, err := attr.Convert(ctx, req.Config, types.StringType)
if err != nil {
  panic(err)
}
var str types.String
diags := tfsdk.ValueAs(ctx, strAttr, &str)
if diags.HasError() {
  panic("oops")
}
// do something with `str`, which is now strongly typed
```

Then no matter what `attr.Type` provider devs use in their schema, this
validator would still work, then. Without the conversion step, it
wouldn't work, as `tfsdk.ValueAs` implementation needs to know the
`attr.Type` of the `attr.Value`, and reusable validators _can't_ know
that. So the point of this helper is to get an `attr.Value` into a known
`attr.Type` format.
Import cycle in tests if we don't.
Being able to return good error messages depends on human-friendly
representations of types existing.
@paddycarver paddycarver merged commit 9fd6d73 into main Sep 14, 2021
@paddycarver paddycarver deleted the paddy_attr_convert branch September 14, 2021 04:38
@github-actions
Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants