Skip to content

Commit af8d738

Browse files
committed
Second round of the initial PR change requests
1 parent 67f5235 commit af8d738

File tree

5 files changed

+35
-5
lines changed

5 files changed

+35
-5
lines changed

docs/guides/materialize_source_table.md

Lines changed: 16 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,12 @@
1+
---
2+
# generated by https://github.com/hashicorp/terraform-plugin-docs
3+
# template file: templates/guides/materialize_source_table.md.tmpl
4+
page_title: "Source Table Migration Guide"
5+
subcategory: ""
6+
description: |-
7+
Guide for migrating to the new materialize_source_table_{source_type} resources.
8+
---
9+
110
# Source versioning: migrating to `materialize_source_table_{source_type}` Resource
211

312
In previous versions of the Materialize Terraform provider, source tables were defined within the source resource itself and were considered subsources of the source rather than separate entities.
@@ -169,7 +178,7 @@ resource "materialize_source_kafka" "kafka_source" {
169178

170179
In the `lifecycle` block, add the `ignore_changes` meta-argument to prevent Terraform from trying to update these attributes during subsequent applies, that way Terraform won't try to update these values based on incomplete information from the state as they will no longer be defined in the source resource itself but in the new `materialize_source_table_{source_type}` resources.
171180

172-
> Note: We will make the changes to those attributes a no-op, so the `ignore_changes` block will not be necessary.
181+
> Note: Once the migration process is fully implemented on the Materialize side and the attributes will have to be updated as no-op in future versions of the provider. That way the `ignore_changes` block will no longer be required. At that point, Terraform will correctly handle these attributes without needing the extra lifecycle configuration. Keep an eye on upcoming releases for this change.
173182
174183
### Step 4: Update Terraform State
175184

@@ -179,6 +188,12 @@ After removing the `table` blocks and the table/topic specific attributes from y
179188

180189
After applying the changes, verify that your tables are still correctly set up in Materialize by checking the table definitions using Materialize's SQL commands.
181190

191+
For a more detailed view of a specific table, you can use the `SHOW CREATE TABLE` command:
192+
193+
```sql
194+
SHOW CREATE TABLE materialize.public.mysql_table1_from_source;
195+
```
196+
182197
## Importing Existing Tables
183198

184199
To import existing tables into your Terraform state, use the following command:

docs/resources/table_grant.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -53,4 +53,4 @@ Import is supported using the following syntax:
5353
terraform import materialize_table_grant.example <region>:GRANT|TABLE|<table_id>|<role_id>|<privilege>
5454

5555
# The region is the region where the database is located (e.g. aws/us-east-1)
56-
```
56+
```

pkg/materialize/source_table_kafka.go

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -201,7 +201,7 @@ func (b *SourceTableKafkaBuilder) Create() error {
201201

202202
if b.format.Protobuf != nil {
203203
if b.format.Protobuf.SchemaRegistryConnection.Name != "" && b.format.Protobuf.MessageName != "" {
204-
options = append(options, fmt.Sprintf(`FORMAT PROTOBUF MESSAGE '%s' USING CONFLUENT SCHEMA REGISTRY CONNECTION %s`, b.format.Protobuf.MessageName, QualifiedName(b.format.Protobuf.SchemaRegistryConnection.DatabaseName, b.format.Protobuf.SchemaRegistryConnection.SchemaName, b.format.Protobuf.SchemaRegistryConnection.Name)))
204+
options = append(options, fmt.Sprintf(`FORMAT PROTOBUF MESSAGE %s USING CONFLUENT SCHEMA REGISTRY CONNECTION %s`, QuoteString(b.format.Protobuf.MessageName), QualifiedName(b.format.Protobuf.SchemaRegistryConnection.DatabaseName, b.format.Protobuf.SchemaRegistryConnection.SchemaName, b.format.Protobuf.SchemaRegistryConnection.Name)))
205205
} else if b.format.Protobuf.SchemaRegistryConnection.Name != "" {
206206
options = append(options, fmt.Sprintf(`FORMAT PROTOBUF USING CONFLUENT SCHEMA REGISTRY CONNECTION %s`, QualifiedName(b.format.Protobuf.SchemaRegistryConnection.DatabaseName, b.format.Protobuf.SchemaRegistryConnection.SchemaName, b.format.Protobuf.SchemaRegistryConnection.Name)))
207207
}

templates/guides/materialize_source_table.md.tmpl

Lines changed: 16 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,12 @@
1+
---
2+
{{ printf "# generated by https://github.com/hashicorp/terraform-plugin-docs" }}
3+
{{ printf "# template file: templates/guides/materialize_source_table.md.tmpl" }}
4+
page_title: "Source Table Migration Guide"
5+
subcategory: ""
6+
description: |-
7+
Guide for migrating to the new materialize_source_table_{source_type} resources.
8+
---
9+
110
# Source versioning: migrating to `materialize_source_table_{source_type}` Resource
211

312
In previous versions of the Materialize Terraform provider, source tables were defined within the source resource itself and were considered subsources of the source rather than separate entities.
@@ -169,7 +178,7 @@ resource "materialize_source_kafka" "kafka_source" {
169178

170179
In the `lifecycle` block, add the `ignore_changes` meta-argument to prevent Terraform from trying to update these attributes during subsequent applies, that way Terraform won't try to update these values based on incomplete information from the state as they will no longer be defined in the source resource itself but in the new `materialize_source_table_{source_type}` resources.
171180

172-
> Note: We will make the changes to those attributes a no-op, so the `ignore_changes` block will not be necessary.
181+
> Note: Once the migration process is fully implemented on the Materialize side and the attributes will have to be updated as no-op in future versions of the provider. That way the `ignore_changes` block will no longer be required. At that point, Terraform will correctly handle these attributes without needing the extra lifecycle configuration. Keep an eye on upcoming releases for this change.
173182

174183
### Step 4: Update Terraform State
175184

@@ -179,6 +188,12 @@ After removing the `table` blocks and the table/topic specific attributes from y
179188

180189
After applying the changes, verify that your tables are still correctly set up in Materialize by checking the table definitions using Materialize's SQL commands.
181190

191+
For a more detailed view of a specific table, you can use the `SHOW CREATE TABLE` command:
192+
193+
```sql
194+
SHOW CREATE TABLE materialize.public.mysql_table1_from_source;
195+
```
196+
182197
## Importing Existing Tables
183198

184199
To import existing tables into your Terraform state, use the following command:

templates/resources/table_grant.md.tmpl

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -21,4 +21,4 @@ description: |-
2121

2222
Import is supported using the following syntax:
2323

24-
{{ codefile "shell" (printf "%s%s%s" "examples/resources/" .Name "/import.sh") }}
24+
{{ codefile "shell" (printf "%s%s%s" "examples/resources/" .Name "/import.sh") }}

0 commit comments

Comments
 (0)