Terraform tablesdb_column type inconsistency

Hi, I am trying out the new terraform provider for appwrite that was introduced a few weeks back. As a first step I wanted to import our existing databases into a terraform state. When I try to import columns of type "string" terraform detects a change and plans a recreation of the column.

I had an example here but the message got too long and I wasn't allowed to post. This is the example https://pastebin.com/XXjCFNVW

So the api tells me the column type is string but terraform interprets type = "string" as a change requiring recreation. For now I am testing in a dev environment but later when I import in prod recreating the column is not an option. Am I misunderstanding something here? I have tried all "similar" types (varchar, text, longtext, mediumtext) just to see if it would have an effect but all lead to the same outcome.

Example from the pastebin above:

curl -XGET -H 'X-Appwrite-Project: my-project-id' -H 'X-Appwrite-Key: my-appwrite-key' 'https://my-appwrite-host.org/v1/tablesdb/my_db/tables/my_table/columns/user_id'

returns

{
  "key": "user_id",
  "type": "string",
  "status": "available",
  "error": "",
  "required": true,
  "array": false,
  "$createdAt": "2025-10-29T14:19:10.427+00:00",
  "$updatedAt": "2025-10-29T14:19:10.457+00:00",
  "size": 128,
  "default": null,
  "encrypt": false
}

But trying to import this into terraform state like

resource "appwrite_tablesdb_column" "my_db_my_table_user_id" {
  database_id = appwrite_tablesdb.my_db.id
  table_id    = appwrite_tablesdb_table.my_db_my_table.id
  type        = "string"
  key         = "user_id"
  array       = false
  default     = null
  encrypt     = false
  required    = true
  size        = 128
}
import {
  to = appwrite_tablesdb_column.my_db_my_table_user_id
  id = "my_db/my_table/user_id"
}

Returns the following change in the terraform plan

  # appwrite_tablesdb_column.my_db_my_table_user_id must be replaced
  # (imported from "my_db/my_table/user_id")
  # Warning: this will destroy the imported resource
-/+ resource "appwrite_tablesdb_column" "my_db_my_table_user_id" {
        array       = false
      ~ created_at  = "2025-10-29T14:19:10.427+00:00" -> (known after apply)
        database_id = "my_db"
        encrypt     = false
        key         = "user_id"
      ~ project_id  = "my-project-id" -> (known after apply)
        required    = true
        size        = 128
        table_id    = "my_table"
      + type        = "string" # forces replacement
      ~ updated_at  = "2025-10-29T14:19:10.457+00:00" -> (known after apply)
    }

cc <@238591617794048000> 👀

<@1501930269677195327> thanks for reaching out, I'll try to debug this first thing tomorrow morning and get back to you with a fix/work-around.

I think I have found the issue, testing it on my side now, before pushing the fix and releasing a new version.

<@1501930269677195327> I have release a new version of the provider, version v1.3.1. Could you try again with the new version?

That seems to have done it! Thanks <@238591617794048000>

While I have you here 😇 Enum columns when returned by the api look like

{
  "key": "foo",
  "type": "string",
  "status": "available",
  "error": "",
  "required": false,
  "array": true,
  "$createdAt": "2025-05-13T12:31:50.479+00:00",
  "$updatedAt": "2025-05-13T12:31:50.505+00:00",
  "elements": [
    "FOO",
    "BAR",
    "BAZ"
  ],
  "format": "enum",
  "default": null
}

An equivalent terraform config, or at least one that does not declare any changes when planning an import, looks like

resource "appwrite_tablesdb_column" "foo" {
  database_id = appwrite_tablesdb.foo.id
  table_id    = appwrite_tablesdb_table.foo.id
  type        = "enum"
  key         = "foo"
  array       = true
  default     = null
  elements = [
    "FOO",
    "BAR",
    "BAZ"
  ]
  required = false
}

It looks like we have lost some specificity. In the api we define "type": "string" and "format": "enum" but in terraform its only type = "enum" . Intuitively I would think the former says "this is an enum where the allowed keys are strings" while the other just says "this is an enum". Is that even a correct assumption or does appwrite not differentiate between different types of enums? If appwrite does differentiate between enum types, what is the way to set this in terraform?

We are running appwrite 1.8.0 self-hosted with the compose file you provide on docker 29.4.1 btw, if that matters

Appwrite only supports string-backed enums, there's no concept of an integer enum or float enum. So "type": "string" + "format": "enum" in the API and type = "enum" in Terraform are expressing the same thing, just in different ways. The provider handles the translation automatically: when creating a column with type = "enum" it calls the correct enum-specific endpoint in the Appwrite SDK, and when reading from the API (including import) it sees type: "string" + format: "enum" and normalizes it back to type = "enum". No specificity is lost, type = "enum" is the correct and complete way to define this in Terraform.

Happy to tackle any other issues you encounter with the provider. Thanks for using it!

Thank you, that clarifies it. If I have any other questions is discord the way to go or would you prefer an issue in you github repo? https://github.com/appwrite/terraform-provider-appwrite

Honestly both work, whatever you prefer. On the github side it is probably easier in terms of tracking the issue being resolved. But here we can have some interaction about the issue at hand.