Provider Schema Inconsistencies #26
Labels
enhancement
New feature or request
Comments
Merged
skorfmann
added a commit
that referenced
this issue
Apr 30, 2020
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
anubhavmishra
pushed a commit
that referenced
this issue
May 5, 2020
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
|
From what I understand, this is intentional and known pattern for the AWS provider, its interface with the AWS API, and backwards compatibility with previous versions of Terraform. The types might be reworked as part of the second iteration of the Provider SDK. See hashicorp/terraform-plugin-sdk/issues/282 for additional context. |
|
@skorfmann wondering if we close since it has similar concern as #25? |
joatmon08
added
bug
|
Closing in favour of #25 |
This was referenced Jul 15, 2020
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
For some reason the semantics of the combination of
computedandoptionaldiffers for attributes in the Terraform provider schema.One example in the s3 bucket resource:
The
arnattribute iscomputedandoptional, but it wouldn't make sense to provide a value for this.For the
bucketattribute, it makes a lot of sense to provide value.Just by looking at the JSON schema, it's impossible to differentiate between the two types. Even by looking at the Go schema it's not possible to differentiate these two types.
I'm wondering if this is just inconsistent by accident, or if it's intentional.
The text was updated successfully, but these errors were encountered: