-
Notifications
You must be signed in to change notification settings - Fork 456
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
Complex Computed Optional Types #25
Comments
This provides a fix for #12 and includes some refactoring around the resource parsing / emitting. The primary goal of the refactoring was, to split the parsing from the emitting to make it easier to understand. I'm still not quite happy with the result (in particular around the models, and that some logic is spread across multiple places). I think it needs another iteration, but for alpha it should do. Right now it's in the "it's working" state, and "jsii" will compile the "AWS" provider without an error. I haven't done a full sanity check of the generated resources, but for the most part it should be usable. In regards to the complex computed types, I'd see it as a first stab at the problem. It's not flexible and serves a very specific use case only. The goal: - Make complex computed types accessible - Provide type information for the computed properties of those types - Keep it within the constraints of jsii, namely no generics and no proxies (see #12) A few issues were created as a follow up - see #24 #25 #26 #27 #28 #29 #39
This provides a fix for #12 and includes some refactoring around the resource parsing / emitting. The primary goal of the refactoring was, to split the parsing from the emitting to make it easier to understand. I'm still not quite happy with the result (in particular around the models, and that some logic is spread across multiple places). I think it needs another iteration, but for alpha it should do. Right now it's in the "it's working" state, and "jsii" will compile the "AWS" provider without an error. I haven't done a full sanity check of the generated resources, but for the most part it should be usable. In regards to the complex computed types, I'd see it as a first stab at the problem. It's not flexible and serves a very specific use case only. The goal: - Make complex computed types accessible - Provide type information for the computed properties of those types - Keep it within the constraints of jsii, namely no generics and no proxies (see #12) A few issues were created as a follow up - see #24 #25 #26 #27 #28 #29 #39
For additional context, see hashicorp/terraform-plugin-sdk/issues/282. May be updated in next version of plugin SDK. |
Related: #124 |
I will provide a list of providers that can help us prioritize working on this issue. |
I'm going to lock this issue because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
There are optional computed complex types in the provider schema, e.g. in the aws_security_group the attributes
egress
/ingress
. Here an excerpt from the schema:As I understand
optional
&&computed
, this means there could beegress
oringress
rules created by AWS. Which, at least foregress
is true. However, apparently the AWS Terraform provider removes thiscomputed
object (see comment)At the moment the attribute is rendered without taking into account the
computed
option, which looks like this:We should probably enable access to the those
computed
rules as well. Something along the lines of this:We'd have to generate:
SecurityGroupEgress
) for theoptional
typeSecurityGroupEgressList
) which implements the interface to wrap thecomputed
valueIn particular the last point seems to be difficult.
For now it's probably fine as is, but when heading towards beta we should come back to this.
The text was updated successfully, but these errors were encountered: