Allow schema rename

[bobbyiliev]

Implementing the schema rename by itself is straight forward, the challenging part is all of the handling of all of the dependant resources, eg all resources that use the SchemaNameSchema.

Closes #334

[bobbyiliev]

The problem here is that if we change the schema name to not be ForceNew, then if someone actually wants to change the name of the schema they will not be able to do that. So there needs to be a mechanism where schema renames are allowed but also they don't break all of the objects that reference that schema.

[benesch]

Yeah. How does this work in other database providers, like PostgreSQL and Snowflake?

[bobbyiliev]

Snowflake does force recreate the dependant objects, eg:

https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/d301b200b45398a1bf1e6e4127983912ba1a52a8/pkg/resources/table.go#L27-L32

They also have some other bugs that affect the way they handle schemas:

Snowflake-Labs/terraform-provider-snowflake#845

The Postgres providers that I've checked do not seem to support this at all, eg. they don't have resources that depend on schema names.

[bobbyiliev]

One option would be to leave the ForceNew as true and then instruct users that they can add an ignore block to the child objects, eg:

resource "materialize_database" "db" {
  name = "db"
}
resource "materialize_schema" "schema" {
  name = "test_schema3"
  database_name = materialize_database.db.name
}

resource "materialize_table" "test_table" {
  name = "test_table"
  schema_name = materialize_schema.schema.name
  # Ignore schema name rename
  lifecycle {
    ignore_changes = [schema_name]
  }
  database_name = materialize_database.db.name
  column {
    name = "id"
    type = "int"
  }
  column {
    name = "name"
    type = "text"
  }
}

That way the schema rename will work as expected, and the child resources will not be recreated and after the rename, the ignore block can be removed as the schema name will be updated correctly in the state file thanks to the read func.

[RobinClowers]

I'm way out of my depth here, but it seems like the easy answer is to not do anything special, which means users have to add the lifecycle ignore blocks like you suggested. If we do decide to set ForceNew to false, what other mechanism would we provide for schema renames?

[RobinClowers]

Might be question we could ask the cloud team, maybe they have suggestions since they have a lot of collective IaC experience?

[bobbyiliev]

After the discussion, I would say that we can take the following plan of action:

• For the short term: Merge this PR as it is as it will still allow people to rename schemas without having to drop all of their dependent objects some manual work by using the lifecycle { ignore_changes = [schema_name] } syntax
• For the long term: Implement schema_id which can be used along side schema_name, I've opened a tracking issue for this as it will be a pretty significant change as 80% of all resources actually depend on the schema_name at the moment: [Epic] Introduce schema_id for all object that use schema_name #472

Open to suggestions! Tagging @jubrad as schema_id was his idea 👏

[bobbyiliev]

@benesch if you are ok with the above ^ we could go ahead and merge this, and after that plan the larger refactor in #472

[benesch]

Oh yes, sorry, absolutely okay with this! It's great to have an MVP!