12 Commits (36cede09f7d8f664efdc542e41b147fa4108d0da)

Author	SHA1	Message	Date
James Bardin	e93d69f18b	more nil/known checks before val.LengthInt	8 years ago
James Bardin	e08a388d3c	check IsKnown on values that may panic	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	32974549cd	plans/objchange: Fix handling of unknown in AssertValueCompatible ... We need to check for the known-ness of the prior value before we check for the null-ness of actual, because it's valid for an unknown value to become a null.	8 years ago
Martin Atkins	8048e9a585	plans/objchange: Don't panic if old or new values are null	8 years ago
Martin Atkins	1aa9ac14cc	plans/objchange: LongestCommonSubsequence ... This algorithm is the usual first step when generating diffs. This package is a bit of a strange home for it, but since it works with changes to cty.Value this feels more natural than any other place it could be.	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	4c78539c2b	plans/objchange: AssertObjectSuperset function ... This function's goal is to ensure that the "final" plan value produced by a provider during the apply step is always consistent with the known parts of the planned value produced during the plan step. Any error produced here indicates a bug in the provider.	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