google_bigquery_table seems to not like valid data type names INT64 and FLOAT64

[jamiet-msm]

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 an 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 an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

0.14.9

Affected Resource(s)

• google_bigquery_table

Terraform Configuration Files

resource "google_bigquery_table" "MonitorAlertPreference" {
  dataset_id  = google_bigquery_dataset.temp_backup.dataset_id
  table_id    = "MonitorAlertPreference"
  description = "Some description"
  project     = var.project_id
  schema      = <<EOF
  [
    {
       "mode": "REQUIRED",
       "name":  "EmailAddress",
       "type":  "STRING"
    },
    {
       "name":  "EmailAlert1",
       "type":  "BOOLEAN"
    },
    {
       "name":  "EmailAlert2",
       "type":  "BOOLEAN"
    },
    {
       "name":  "ExtractAuditKey",
       "type":  "INT64"
    }
  ]
  EOF
}

Debug Output

Expected Behavior

When running terraform apply after the table above has already been created terraform should not try and make any changes to the table. The type of column ExtractAuditKey is INT64 which is listed at https://cloud.google.com/bigquery/docs/reference/standard-sql/data-types as the name of a data type.

Actual Behavior

When running terraform apply after the table above has already been created terraform deems it necessary to change the type of column ExtractAuditKey:

~ resource "google_bigquery_table" "MonitorAlertPreference" {
        id                  = "projects/myproject/datasets/mydataset/tables/MonitorAlertPreference"
      ~ schema              = jsonencode(
          ~ [
                # (2 unchanged elements hidden)
                {
                    name = "EmailAlert2"
                    type = "BOOLEAN"
                },
              ~ {
                  ~ type = "INTEGER" -> "INT64"
                    # (1 unchanged element hidden)
                },
            ]
        )
        # (15 unchanged attributes hidden)
    }

We can prevent this from happening by changing the table definition to:

resource "google_bigquery_table" "MonitorAlertPreference" {
  dataset_id  = google_bigquery_dataset.temp_backup.dataset_id
  table_id    = "MonitorAlertPreference"
  description = "Some description"
  project     = var.project_id
  schema      = <<EOF
  [
    {
       "mode": "REQUIRED",
       "name":  "EmailAddress",
       "type":  "STRING"
    },
    {
       "name":  "EmailAlert1",
       "type":  "BOOLEAN"
    },
    {
       "name":  "EmailAlert2",
       "type":  "BOOLEAN"
    },
    {
       "name":  "ExtractAuditKey",
       "type":  "INTEGER"
    }
  ]
  EOF
}

however we're of the opinion that we shouldn't have to. We have used the correct name of the data type as per the documentation so why is it being changed? If I look at the table in bigquery it does state the data type as being INTEGER, not INT64, so I'm assuming that INTEGER & INT64 are considered synonyms of each other. if that is the case then terraform shouldn't recognise them as being different in my opinion.

Interested in your thoughts.

We have the same issue with columns of type FLOAT64/FLOAT too by the way.

Steps to Reproduce

1. terraform apply
2. terraform apply

[edwardmedia]

@jamiet-msm I can't repro. What version of the provider are you using? If you use an old version, can you try the latest version? It would be great if you can share the apply debug log

[edwardmedia]

@jamiet-msm is this still an issue?

[jamiet-msm]

Hi @edwardmedia , Apologies for the delay in replying.

• Yep, its still an issue
• provider version is 3.58.0
• I have the debug (aka trace) log. i.e. The log I get from setting TF_LOG=TRACE & TF_LOG_PATH. Its 10MB (528KB zipped), can you suggest a way that I can get it to you?

[edwardmedia]

@jamiet-msm here is the code that is expected to addresses INTEGER & INT64 are considered synonyms of each other.

There are several issues related to this. Below is one of them that might help follow the issue.
#1144

Can you try the provider of the latest version to see if this is still an issue? 10MB is big. You may post several requests & response related to the table?

[edwardmedia]

@jamiet-msm based on the latest code and the fact I can't repro the issue, I am closing this issue now. If you see the issue remains, please provide the details so I can follow and repro. Thanks

[jamiet-msm]

Hi @edwardmedia
Thx for persevering and apologies for not replying sooner.

I have good news tho. Upgrading to the latest version of the provider has solved the problem. We were on 3.51.0, we're now on 3.63.0. It looks like the fix is in this commit: a8ff070 on 2021-01-15 and it made it into 3.56.0.

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!