Commit Graph

10 Commits

Author SHA1 Message Date
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
Paul Hinze edaf5795a5 Merge pull request #3257 from fatih/fix-nil-setting-schema
schema: delete non existing values
2015-12-08 20:15:00 -06:00
Panagiotis Moustafellos e4845f75cc removed extra parentheses 2015-10-08 15:48:04 +03:00
Fatih Arslan f269d4fc8c schema: add test for nil string case 2015-09-16 23:35:10 +03:00
Mitchell Hashimoto 9b8b38cbb1 helper/schema: test that set can be nil 2015-02-18 14:59:55 -08:00
Mitchell Hashimoto e4f0f6b15d helper/schema: more tests 2015-02-18 14:44:46 -08:00
Mitchell Hashimoto e32cd396ad helper/schema: add test for GH-814 2015-01-16 08:37:25 -08:00
Mitchell Hashimoto 448887f3c4 helper/schema: map counts in state 2015-01-15 14:12:24 -08:00
Mitchell Hashimoto f64b09a045 helper/schema: more tests 2015-01-10 11:49:37 -08:00
Mitchell Hashimoto 03c6453a72 helper/schema: FieldWriter, replace Set 2015-01-10 11:44:26 -08:00