Fixed `SqlColumnInfo` for `force_new`

[tanmay-db]

trafficstars

Changes

We need to mark the fields as force_new since they are part of structure. As updating column isn't supported, we mark all the fields as force_new.

Relevant code ref:

ColumnInfos []SqlColumnInfo `json:"columns,omitempty" tf:"alias:column,computed,force_new"`

This doesn't seem to be regression on TF side, this test fails on 1.35.0 commit as well.

Tests

TestUcAccResourceSqlTable_Managed passes after change

• [ ] make test run locally
• [ ] relevant change in docs/ folder
• [ ] covered with integration tests in internal/acceptance
• [ ] relevant acceptance tests are passing
• [ ] using Go SDK

[alexott]

Imho it's too dangerous... We may need something like this: https://github.com/databricks/terraform-provider-databricks/pull/2424

[nkvuong]

@alexott we don't support any column update for databricks_sql_table at the moment, this is covers the gap where changes to column types are ignored by updates.

as a short-term fix, this is ok, but long-term fix is to add support for column updates to databricks_sql_table

[mgyucht]

@alexott @nkvuong Do you know how https://github.com/databricks/terraform-provider-databricks/blob/main/internal/acceptance/sql_table_test.go#L39-L66 succeeded in the past? Updating the type of the table would not cause the table to be deleted/recreated, but as a result, there should still have been a diff in the type of this column.

I believe this was the intention from the start, as SqlColumnInfos is annotated with ForceNew. However, in the SDKv2, my understanding is that ForceNew on TypeList attributes will only cause the resource to be deleted/recreated when the number of entries in the list changes. In this case, the table would be recreated when columns are added and removed, but not if the number of columns remains unchanged.

In any case: lack of update support has been raised a number of times: https://github.com/databricks/terraform-provider-databricks/issues/3001. We can patch this to prevent diffs from appearing when users change the types of a column, but this is really just covering up an underlying lack of support of updating table schema. Rather than patch this like this, can we address the root cause by simply supporting updates to tables & issuing ALTER TABLE statements to modify columns?