Commit Graph

18 Commits

Author SHA1 Message Date
Clint a84aa5e914 Revert "helper/schema: Make nested Set(s) in List(s) work" (#7436) 2016-06-30 10:48:52 -05:00
Radek Simko 37d57f4a85 Improve naming convention (resultSet -> exists) 2016-06-28 17:40:45 +01:00
Radek Simko 917ad44cf0 helper/schema: Fix readSet implementation (DiffFieldReader) 2016-06-28 17:40:44 +01:00
Radek Simko c738c5a9a3 helper/schema: Implement reader-specific readList method 2016-06-28 17:40:44 +01:00
James Nugent 074545e536 core: Use .% instead of .# for maps in state
The flatmapped representation of state prior to this commit encoded maps
and lists (and therefore by extension, sets) with a key corresponding to
the number of elements, or the unknown variable indicator under a .# key
and then individual items. For example, the list ["a", "b", "c"] would
have been encoded as:

    listname.# = 3
    listname.0 = "a"
    listname.1 = "b"
    listname.2 = "c"

And the map {"key1": "value1", "key2", "value2"} would have been encoded
as:

    mapname.# = 2
    mapname.key1 = "value1"
    mapname.key2 = "value2"

Sets use the hash code as the key - for example a set with a (fictional)
hashcode calculation may look like:

    setname.# = 2
    setname.12312512 = "value1"
    setname.56345233 = "value2"

Prior to the work done to extend the type system, this was sufficient
since the internal representation of these was effectively the same.
However, following the separation of maps and lists into distinct
first-class types, this encoding presents a problem: given a state file,
it is impossible to tell the encoding of an empty list and an empty map
apart. This presents problems for the type checker during interpolation,
as many interpolation functions will operate on only one of these two
structures.

This commit therefore changes the representation in state of maps to use
a "%" as the key for the number of elements. Consequently the map above
will now be encoded as:

    mapname.% = 2
    mapname.key1 = "value1"
    mapname.key2 = "value2"

This has the effect of an empty list (or set) now being encoded as:

    listname.# = 0

And an empty map now being encoded as:

    mapname.% = 0

Therefore we can eliminate some nasty guessing logic from the resource
variable supplier for interpolation, at the cost of having to migrate
state up front (to follow in a subsequent commit).

In order to reduce the number of potential situations in which resources
would be "forced new", we continue to accept "#" as the count key when
reading maps via helper/schema. There is no situation under which we can
allow "#" as an actual map key in any case, as it would not be
distinguishable from a list or set in state.
2016-06-09 10:49:42 +01:00
Martin Atkins cc8e8a55de helper/schema: Default hashing function for sets
A common issue with new resource implementations is not considering parts
of a complex structure that's used inside a set, which causes quirky
behavior.

The schema helper has enough information to provide a default reasonable
implementation of a set function that includes all non-computed attributes
in a deterministic way. Here we implement such a function and use it
when no explicit hashing function is provided.

In order to achieve this we encapsulate the construction of the zero
value for a schema in a new method schema.ZeroValue, which allows us to
put the fallback logic to the new default function in a single spot.
It is no longer valid to use &Set{F: schema.Set} and all uses of that
construct should be replaced with schema.ZeroValue().(*Set) .
2015-10-03 18:10:47 -07:00
Mitchell Hashimoto 6e509aedcb helper/schema: diff should include removed set items [GH-1823] 2015-06-25 21:52:49 -07:00
Sam Boyer b82bd0c280 Condense switch fallthroughs into expr lists 2015-05-26 21:52:36 -04:00
Mitchell Hashimoto 2212d6895d helper/schema: diff with set going to 0 elements removes it from state 2015-02-17 11:38:56 -08:00
Paul Hinze 4e8e3dad86 DiffFieldReader: filter all '#' fields from sets
Now that readMap filters out '#' fields, when maps are nested in sets,
we exposed a related bug where a set was iterating over nested maps and
expected the '#' key to be present in those nested maps.

By skipping _all_ count fields when iterating over set keys, all is
right with the world again.
2015-02-04 09:25:45 -06:00
Paul Hinze 219aa3e788 helper/schema: fix DiffFieldReader map handling
An `InstanceDiff` will include `ResourceAttrDiff` entries for the
"length" / `#` field of maps. This makes sense, since for something like
`terraform plan` it's useful to see when counts are changing.

The `DiffFieldReader` was not taking these entries into account when
reading maps out, and was therefore incorrectly returning maps that
included an extra `'#'` field, which was causing all sorts of havoc
for providers (extra tags on AWS instances, broken google compute
instance launch, possibly others).

 * fixes #914 - extra tags on AWS instances
 * fixes #883 - general core issue sprouted from #757
 * removes the hack+TODO from #757
2015-02-03 20:17:57 -06:00
Dave Cunningham 18c26cb2eb Add some missing Float cases 2015-01-28 12:53:34 -05:00
Mitchell Hashimoto 1fcd24cf67 helper/schema: add float type 2015-01-10 16:04:01 -08:00
Mitchell Hashimoto b4bf813151 helper/schema: too big to fail 2015-01-08 18:02:19 -08:00
Mitchell Hashimoto 7e379cb1a1 helper/schema: field readers no longer take a schema as arg 2015-01-03 12:13:46 -05:00
Mitchell Hashimoto 0b1da37b20 helper/schema: diff field reader should merge result with source 2015-01-03 09:55:38 -05:00
Mitchell Hashimoto 91a57b42e8 helper/schema: reading a diff with computed should return zero value 2015-01-03 12:02:49 +05:30
Mitchell Hashimoto 73726e83b2 helper/schema: DiffFieldReader for reading data from a diff 2014-12-20 02:17:35 +05:30