16 Commits (ddac28255356e8d0737721cfcc1d00a0fb7c95e4)

Author	SHA1	Message	Date
James Bardin	77af322c1c	handle non-null, but empty NestingMap in a set	6 years ago
James Bardin	b59c64245b	refactor ifs to reduce indentation	6 years ago
James Bardin	f128b8c4fa	take dynamic types into account when comparing set ... If a NestingList or NestingMap contains a dynamic type, they must be handled as a cty.Tuple and cty.Object respectively, because the elements may not have precisely matching types.	6 years ago
Alexander Ovechkin	8fbb4d0163	Converting ListVal to ListVal instead of TupleVal in setElementCompareValue	6 years ago
Martin Atkins	88e76fa9ef	configs/configschema: Introduce the NestingGroup mode for blocks ... In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.	7 years ago
Martin Atkins	87fe6cbecd	plans/objchange: Don't panic when prior state contains nested map blocks ... We were using the wrong cty operation to access map members, causing a panic whenever a prior value was present for a resource type with a nested block backed by a map value.	7 years ago
James Bardin	e50be82da4	don't add empty blocks in ProposedNewObject ... If the config contained a null block, don't convert it to a block with empty values for the proposed new value.	7 years ago
Martin Atkins	312d798a89	core: Restore our EvalReadData behavior ... In an earlier commit we changed objchange.ProposedNewObject so that the task of populating unknown values for attributes not known during apply is the responsibility of the provider's PlanResourceChange method, rather than being handled automatically. However, we were also using objchange.ProposedNewObject to construct the placeholder new object for a deferred data resource read, and so we inadvertently broke that deferral behavior. Here we restore the old behavior by introducing a new function objchange.PlannedDataResourceObject which is a specialized version of objchange.ProposedNewObject that includes the forced behavior of populating unknown values, because the provider gets no opportunity to customize a deferred read. TestContext2Plan_createBeforeDestroy_depends_datasource required some updates here because its implementation of PlanResourceChange was not handling the insertion of the unknown value for attribute "computed". The other changes here are just in an attempt to make the flow of this test more obvious, by clarifying that it is simulating a -refresh=false run, which effectively forces a deferred read since we skip the eager read that would normally happen in the refresh step.	7 years ago
Martin Atkins	c794bf5bcc	plans/objchange: Don't presume unknown for values unset in config ... Previously we would construct a proposed new state with unknown values in place of any not-set-in-config computed attributes, trying to save the provider a little work in specifying that itself. Unfortunately that turns out to be problematic because it conflates two concerns: attributes can be explicitly set in configuration to an unknown value, in which case the final result of that unknown overrides any default value the provider might normally populate. In other words, this allows the provider to recognize in the proposed new state the difference between an Optional+Computed attribute being set to unknown in the config vs not being set in the config at all. The provider now has the responsibility to replace these proposed null values with unknown values during PlanResourceChange if it expects to select a value during the apply step. It may also populate a known value if the final result can be predicted at plan time, as is the case for constant defaults specified in the provider code. This change comes from a realization that from core's perspective the helper/schema ideas of zero values, explicit default values, and customizediff tweaks are all just examples of "defaults", and by allowing the provider to see during plan whether these attributes are being explicitly set in configuration and thus decide whether the default will be provided immediately during plan or deferred until apply.	7 years ago
James Bardin	e93d69f18b	more nil/known checks before val.LengthInt	8 years ago
Martin Atkins	9b4b43c077	plans/objchange: Don't panic when a prior value with a set is null ... ProposedNewObject intentionally replaces a null prior with an unknown prior in order to easily fill in unknown values where they "show through" under values not set explicitly in config, but it was failing to handle that situation when dealing with nested blocks that are backed by sets.	8 years ago
Kristin Laemmert	c661157999	plans/objchange: further harden ProposedNewObject against ~weird~ ... incoming values Addresses an odd state where the priorV of an object to be changed is known but null. While this situation should not happen, it seemed prudent to ensure that core is resilient to providers sending incorrect values (which might also occur with manually edited state).	8 years ago
Kristin Laemmert	2a8aa6a139	plans/objchange: if priorV is unknown, fall through to the recursive call to `ProposedNewObject`	8 years ago
Martin Atkins	3f8a973846	plans/objchange: when prior is null, computed attributes are unknown	8 years ago
Martin Atkins	549544f201	configschema: Handle nested blocks containing dynamic-typed attributes ... We need to make the collection itself be a tuple or object rather than list or map in this case, since otherwise all of the elements of the collection are constrained to be of the same type and that isn't the intent of a provider indicating that it accepts any type.	8 years ago
Martin Atkins	0317da9911	plans/objchange: logic for merging prior state with config ... This produces a "proposed new state", which already has prior computed values propagated into it (since that behavior is standard for all resource types) but could be customized further by the provider to make the "_planned_ new state". In the process of implementing this it became clear that our configschema DecoderSpec behavior is incorrect, since it's producing list values for NestingList and map values for NestingMap. While that seems like it should be right, we should actually be using tuple and object types respectively to allow each block to have a different runtime type in situations where an attribute is given the type cty.DynamicPseudoType. That's not fixed here, and so without a further fix list and map blocks will panic here. The DecoderSpec implementation will be fixed in a subsequent commit.	8 years ago