Treat column mode = NULLABLE and unspecified column mode as the same

[jasonmcboyd]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

I'm not sure if this is a bug report or a feature request.

If a big query table is created with a column that has the mode left unspecified and then later the mode is changed to "NULLABLE" terraform plan will indicate an update is required:

 ​~ schema              = jsonencode(
	 ​~ [
		 ​~ {
			 ​+ mode = "NULLABLE"
			   ​name = "AccountID"
			   ​type = "NUMERIC"
		   ​},
		 ​  <ommitted for brevity>
	   ​]
   ​)

I understand why no change is made but I think, given that mode defaults to "NULLABLE" when no mode is specified, the provider should treat these as the same and not indicate that an update is required.

New or Affected Resource(s)

• google_bigquery_table

Potential Terraform Configuration

No new configuration proposed. Just amended plan output.

References

• #0000

[danawillow]

Hi @jasonmcboyd, the docs at https://www.terraform.io/docs/providers/google/r/bigquery_table.html#schema say:

~>NOTE: Because this field expects a JSON string, any changes to the string will create a diff, even if the JSON itself hasn't changed. If the API returns a different value for the same schema, e.g. it switched the order of values or replaced STRUCT field type with RECORD field type, we currently cannot suppress the recurring diff this causes. As a workaround, we recommend using the schema as returned by the API.

Unfortunately this is just another instance of that case. Marking as a persistent bug because fixing it would be tricky and require us to do some thinking about how we handle diffs on json fields. I don't expect us to get around to it any time soon though.

[melinath]

duplicate of #7979

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.