Commit Graph

20 Commits

Author SHA1 Message Date
James Bardin 7075bc9a4d restrict the ComputedKeys usage to containers
Computed primitive values must see the UnknownConfigValue or they are
assumed to be unchanged. Restrict the usage of the protov5 ComputedKeys
to containers.
2019-05-06 19:19:10 -04:00
James Bardin 133d3d7971 check for computed values in the config
First check the ComputedValues field in the config when reading config
field, so that we can detect if there is an unknown value in a
container. Since maps, lists and sets are verified to exist by looking
for a "length" first, an unknown config value in the config is ignored.
2019-05-02 14:08:40 -07:00
James McGill 035d56409f helper/schema: handle TypeMap elem consistently with other collection types
For historical reasons, the handling of element types for maps is inconsistent with other collection types.

Here we begin a multi-step process to make it consistent, starting by supporting both the "consistent" form of using a schema.Schema and an existing erroneous form of using a schema.Type directly. In subsequent commits we will phase out the erroneous form and require the schema.Schema approach, the same as we do for TypeList and TypeSet.
2018-03-14 14:50:41 -07:00
Mitchell Hashimoto 487a37b0dd
helper/schema: PromoteSingle for legacy support of "maybe list" types 2017-01-26 15:09:15 -08:00
James Bardin 01be1a5ecd Check for interpolated values when reading a map
Accessing an interpolated value in a map through ConfigFieldReader can
fail, because GetRaw can't access interpolated values, so check if the
value exists at all by looking in the config. If the config has a value,
assume our map's value is interpolated and proceed as such.

We also need to lookup the correct schema to properly read a field from
a nested structure.

- Maps previously always defaulted to TypeString. Now check if Elem is a
  ValueType and use that if applicable
- Lists now return the schema for nested element types, defaulting to a
  TypeString like maps.

This only allows maps and lists to be nested one level deep, and the
inner map or list must only contain string values.
2016-11-28 09:04:24 -05:00
James Bardin c4eefd4b5e Allow primitive type in maps via all FieldReaders
Now that we can read primitive type out of a map, each field reader
needs to be able to set the proper type as expected.
2016-11-17 15:35:08 -05:00
Clint a84aa5e914 Revert "helper/schema: Make nested Set(s) in List(s) work" (#7436) 2016-06-30 10:48:52 -05:00
Radek Simko c738c5a9a3 helper/schema: Implement reader-specific readList method 2016-06-28 17:40:44 +01:00
James Nugent 7b6df27e4a helper/schema: Read native maps from configuration
This adds a test and the support necessary to read from native maps
passed as variables via interpolation - for example:

```
resource ...... {
     mapValue = "${var.map}"
}
```

We also add support for interpolating maps from the flat-mapped resource
config, which is necessary to support assignment of computed maps, which
is now valid.

Unfortunately there is no good way to distinguish between a list and a
map in the flatmap. In lieu of changing that representation (which is
risky), we assume that if all the keys are numeric, this is intended to
be a list, and if not it is intended to be a map. This does preclude
maps which have purely numeric keys, which should be noted as a
backwards compatibility concern.
2016-05-10 14:49:14 -04:00
Sander van Harmelen ef4726bd50 Change Set internals and make (extreme) performance improvements
Changing the Set internals makes a lot of sense as it saves doing
conversions in multiple places and gives a central place to alter
the key when a item is computed.

This will have no side effects other then that the ordering is now
based on strings instead on integers, so the order will be different.
This will however have no effect on existing configs as these will
use the individual codes/keys and not the ordering to determine if
there is a diff or not.

Lastly (but I think also most importantly) there is a fix in this PR
that makes diffing sets extremely more performand. Before a full diff
required reading the complete Set for every single parameter/attribute
you wanted to diff, while now it only gets that specific parameter.

We have a use case where we have a Set that has 18 parameters and the
set consist of about 600 items (don't ask 😉). So when doing a diff
it would take 100% CPU of all cores and stay that way for almost an
hour before being able to complete the diff.

Debugging this we learned that for retrieving every single parameter
it made over 52.000 calls to `func (c *ResourceConfig) get(..)`. In
this function a slice is created and used only for the duration of the
call, so the time needed to create all needed slices and on the other
hand the time the garbage collector needed to clean them up again caused
the system to cripple itself. Next to that there are also some expensive
reflect calls in this function which also claimed a fair amount of CPU
time.

After this fix the number of calls needed to get a single parameter
dropped from 52.000+ to only 2! 😃
2015-11-22 14:21:28 +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
Sam Boyer b82bd0c280 Condense switch fallthroughs into expr lists 2015-05-26 21:52:36 -04:00
Mitchell Hashimoto fa934d96d0 helper/schema: FieldReaderConfig detects computed maps 2015-04-21 22:07:52 +02:00
Paul Hinze 5d4e69cc80 helper/schema: apply schema defaults at the field level when reading from config
We were waiting until the higher-level (m schemaMap) diffString method
to apply defaults, which was messing with set hashcode evaluation for
cases when a field with a default is included in the hash function.

fixes #824
2015-01-27 18:18:57 -06:00
Mitchell Hashimoto 1fcd24cf67 helper/schema: add float type 2015-01-10 16:04:01 -08:00
Mitchell Hashimoto 361d00347a helper/schema: refactor tests for fieldreader to be common 2015-01-10 12:42:15 -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 73726e83b2 helper/schema: DiffFieldReader for reading data from a diff 2014-12-20 02:17:35 +05:30
Mitchell Hashimoto 9447973015 helper/schema: ConfigFieldReader and generic helpers 2014-12-19 22:52:53 +05:30