15 Commits (cdcff09d99d8d1a0142f583f7fab650ca54e781d)

Author	SHA1	Message	Date
James Nugent	dbf725bd68	core: Allow dynamic attributes in helper/schema ... The helper/schema framework for building providers previously validated in all cases that each field being set in state was in the schema. However, in order to support remote state in a usable fashion, the need has arisen for the top level attributes of the resource to be created dynamically. In order to still be able to use helper/schema, this commit adds the capability to assign additional fields. Though I do not forsee this being used by providers other than remote state (and that eventually may move into Terraform Core rather than being a provider), the usage and semantics are: To opt into dynamic attributes, add a schema attribute named "__has_dynamic_attributes", and make it an optional string with no default value, in order that it does not appear in diffs: "__has_dynamic_attributes": { Type: schema.TypeString Optional: true } In the read callback, use the d.UnsafeSetFieldRaw(key, value) function to set the dynamic attributes. Note that other fields in the schema _are_ copied into state, and that the names of the schema fields cannot currently be used as dynamic attribute names, as we check to ensure a value is not already set for a given key.	10 years ago
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.	10 years ago
Paul Hinze	069425a700	consul: Fix several problems w/ consul_keys update ... Implementation notes: * The hash implementation was not considering key value, causing "diffs did not match" errors when a value was updated. Switching to default HashResource implementation fixes this * Using HashResource as a default exposed a bug in helper/schema that needed to be fixed so the Set function is picked up properly during Read * Stop writing back values into the `key` attribute; it triggers extra diffs when `default` is used. Computed values all just go into `var`. * Includes a state migration to prevent unnecessary diffs based on "key" attribute hashcodes changing. In the tests: * Switch from leaning on the public demo Consul instance to requiring a CONSUL_HTTP_ADDR variable be set pointing to a `consul agent -dev` instance to be used only for testing. * Add a test that exposes the updating issues and covers the fixes Fixes #774 Fixes #1866 Fixes #3023	10 years ago
Paul Hinze	edaf5795a5	Merge pull request #3257 from fatih/fix-nil-setting-schema ... schema: delete non existing values	11 years ago
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! 😃	11 years ago
Fatih Arslan	8e7fc240f9	schema: delete non existing values ... We need to set the value to an empty value so the state file does indeed change the value. Otherwise the obsolote value is still intact and doesn't get changed at all. This means `terraform show` still shows the obsolote value when the particular value is not existing anymore. This is due the AWS API which is returning a null instead of an empty string.	11 years ago
Sam Boyer	b82bd0c280	Condense switch fallthroughs into expr lists	11 years ago
Paul Hinze	f2368428d3	helper/schema: write "attr.#": "0" for empty maps ... This fixes some perpetual diffs I saw in Atlas AccTests where an empty map (`map[string]interface{}{}`) was being `d.Set` for "metadata_full". Because the MapFieldWriter was not distinguishing between empty and nil, this trigger the "map delete" logic and no count was written to the state. This caused subsequent plans to improperly report a diff. Here we redefine the map delete functionality to explicitly trigger only on `nil`, so we catch the `.#` field for empty maps.	11 years ago
Dave Cunningham	aa2015ccd0	Fix failing tests	11 years ago
Dave Cunningham	18c26cb2eb	Add some missing Float cases	11 years ago
Sander van Harmelen	2edfd0e89d	Just my OCD playing up 😉	11 years ago
Greg Osuri	2769d7cf9c	Fixes #813: Ensuring set count (.#) is written to the state	11 years ago
Greg Osuri	f870eff5f9	core: fix for #813 - added a gaurd for interface conversion	11 years ago
Mitchell Hashimoto	448887f3c4	helper/schema: map counts in state	11 years ago
Mitchell Hashimoto	03c6453a72	helper/schema: FieldWriter, replace Set	11 years ago