-
Notifications
You must be signed in to change notification settings - Fork 98
Refactor Schema and Schema Data Related Documentation #418
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
Comments
This updated documentation should also contain a reference page for schema block support. |
…essing schema data Reference: #498 Reference: #418 Reference: https://discuss.hashicorp.com/t/terraform-plan-does-not-allow-sending-only-delta-for-list-type-parameters-in-the-resource-block/45027 Reference: https://discuss.hashicorp.com/t/set-state-for-optional-nested-attributes-for-singlenestedattributes/44838/2 Reference: https://discuss.hashicorp.com/t/why-is-req-plan-get-in-my-create-method-throwing-an-error/44441/2 Reference: https://discuss.hashicorp.com/t/terraform-plugin-framework-value-conversion-error-unhandled-unknown-value/44382/3 ... plenty more ... The current recommendation is now to always use `types` package types, unless there is no chance for null/unknown values. The conversion rules sections will likely be further handled in #418 by having a schema conversion page that outlines how to map each framework-defined type into value types.
…essing schema data (#504) Reference: #498 Reference: #418 Reference: https://discuss.hashicorp.com/t/terraform-plan-does-not-allow-sending-only-delta-for-list-type-parameters-in-the-resource-block/45027 Reference: https://discuss.hashicorp.com/t/set-state-for-optional-nested-attributes-for-singlenestedattributes/44838/2 Reference: https://discuss.hashicorp.com/t/why-is-req-plan-get-in-my-create-method-throwing-an-error/44441/2 Reference: https://discuss.hashicorp.com/t/terraform-plugin-framework-value-conversion-error-unhandled-unknown-value/44382/3 ... plenty more ... The current recommendation is now to always use `types` package types, unless there is no chance for null/unknown values. The conversion rules sections will likely be further handled in #418 by having a schema conversion page that outlines how to map each framework-defined type into value types.
The updated documentation should also contain complex data modeling and provider logic (e.g. nested lists, nested attributes) |
…n "Getting Started" section (#418)
…resources - plan modification (#418)
…resources - state upgraders (#418)
…attributes & blocks - attribute schema (#418)
…attributes & blocks - attribute types (#418)
…attributes & blocks - attribute fields (#418)
…attributes & blocks - default values (#418)
…attributes & blocks - force new (#418)
…attributes & blocks - validators predefined (#418)
…attributes & blocks - validators custom (#418)
…attributes & blocks - blocks (#418)
…attributes & blocks - blocks computed (#418)
…ing Data - Terraform Concepts"(#418)
…tarted - Code Walthrough" (#418)
…Handling Data - Blocks" page (#418)
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. |
Module version
Use-cases
The website documentation is less than ideal as it has quite a few schema-related pages as top-level in the lengthy side navigation. In particular:
It would be clearer if these were bundled together as they are conceptually related.
Proposal
Create a new top-level section named "Schemas and Schema Data" or "Schemas and Config/Plan/State" with the following:
Doing this will likely warrant fixing wording/flow for all the concepts/pages to ensure they seem cohesive together.
References
The text was updated successfully, but these errors were encountered: