Name change

Author: kbatuigas

modules/manage/partials/iceberg/about-iceberg-topics.adoc

@@ -133,7 +133,7 @@ For details on the partitioning specification, including allowed transforms, see
 --
 * `key_value`: Creates an Iceberg table using a simple schema, consisting of two columns, one for the record metadata including the key, and another binary column for the record's value.
 * `value_schema_id_prefix`: Creates an Iceberg table whose structure matches the Redpanda schema for this topic, with columns corresponding to each field. You must register a schema in the Schema Registry (see next step), and producers must write to the topic using the Schema Registry wire format. Redpanda parses the schema used by the record based on the schema ID encoded in the payload header and stores the topic values in the corresponding table columns.
-* `value_subject_latest`: Creates an Iceberg table whose structure matches the latest schema registered for the subject in the Schema Registry.
+* `value_schema_latest`: Creates an Iceberg table whose structure matches the latest schema registered for the subject in the Schema Registry.
 * `disabled` (default): Disables writing to an Iceberg table for this topic.
 --
 +
@@ -177,12 +177,13 @@ The Iceberg table resides in a namespace called `redpanda` and has the same name
 
 == About schema support and translation to Iceberg format
 
-The `redpanda.iceberg.mode` topic property determines how Redpanda maps the topic data to the Iceberg table structure. You can use the `value_schema_id_prefix` and `value_subject_latest` modes to generate an Iceberg table that matches the structure of an Avro or Protobuf schema in the Schema Registry, or you can use the `key_value` mode where Redpanda stores the record values as-is in the table. 
+The `redpanda.iceberg.mode` topic property determines how Redpanda maps the topic data to the Iceberg table structure. You can use the `value_schema_id_prefix` and `value_schema_latest` modes to generate an Iceberg table that matches the structure of an Avro or Protobuf schema in the Schema Registry, or you can use the `key_value` mode where Redpanda stores the record values as-is in the table. 
 
 The JSON Schema format is not supported. If your topic data is in JSON, use the `key_value` mode. 
 
+// TODO: Remove conditional once topic property page is available in Cloud
 ifndef::env-cloud[]
-See the xref:reference:properties/topic-properties.adoc#redpanda-iceberg-mode[`redpanda.iceberg.mode` property reference] for more details, including allowed syntax for `value_subject_latest`.
+See the xref:reference:properties/topic-properties.adoc#redpanda-iceberg-mode[`redpanda.iceberg.mode` property reference] for more details, including allowed syntax for `value_schema_latest`.
 endif::[]
 
 === Iceberg modes and table schemas
@@ -231,7 +232,7 @@ CREATE TABLE ClickEvent (
 
 Consider this approach if the topic data is in JSON, or if you can use the Iceberg data in its semi-structured format.
 
-The `value_schema_id_prefix` and `value_subject_latest` modes translate to the following table format:
+The `value_schema_id_prefix` and `value_schema_latest` modes translate to the following table format:
 
 [,sql]
 ----
@@ -257,7 +258,7 @@ ifdef::env-cloud[]
 With schema integration using the `value_schema_id_prefix` mode, Redpanda uses the Schema Registry wire format, which embeds the magic byte and schema ID in the message payload header. Producers to the topic must use the wire format in the serialization process so Redpanda can determine the schema used for each record, parse the record according to that schema, and use the schema to define the Iceberg table. See also: the https://www.redpanda.com/blog/schema-registry-kafka-streaming#how-does-serialization-work-with-schema-registry-in-kafka[Understanding Apache Kafka Schema Registry^] blog post.
 endif::[]
 
-The `value_subject_latest` mode uses the latest schema registered for the subject in the Schema Registry. This mode is similar to the `value_schema_id_prefix` mode, but it does not require that producers use the wire format. 
+The `value_schema_latest` mode uses the latest schema registered for the subject in the Schema Registry. This mode is similar to the `value_schema_id_prefix` mode, but it does not require that producers use the wire format. 
 
 If Redpanda fails to translate the record to the columnar format as defined by the schema, it writes the record to a dead-letter queue (DLQ) table. See <<manage-dead-letter-queue,Manage dead-letter queue>> for more information.
 

modules/manage/partials/iceberg/query-iceberg-topics.adoc

@@ -43,7 +43,7 @@ endif::[]
 {"user_id": 2324, "event_type": "BUTTON_CLICK", "ts": "2024-11-25T20:23:59.380Z"}
 ----
 
-=== Topic with schema (`value_schema_id_prefix` or `value_subject_latest` mode)
+=== Topic with schema (`value_schema_id_prefix` or `value_schema_latest` mode)
 
 Assume that you have created the `ClickEvent` topic, set `redpanda.iceberg.mode` to `value_schema_id_prefix`, and are connecting to a REST-based Iceberg catalog. The following is an Avro schema for `ClickEvent`:
 

modules/reference/pages/properties/topic-properties.adoc

@@ -538,24 +538,24 @@ Enable the Iceberg integration for the topic. You can choose one of three modes.
 
 - `key_value`: Creates an Iceberg table with a `Key` column and a `Value` column. Redpanda stores the raw topic content in the `Value` column.
 - `value_schema_id_prefix`: Creates an Iceberg table whose structure matches the Redpanda schema for the topic, with columns corresponding to each field. Redpanda uses the Schema Registry wire format, consisting of the "magic byte" and schema ID encoded in the payload header, to parse the topic values per field and store them in the corresponding table columns.
-- `value_subject_latest`: Creates an Iceberg table whose structure matches the latest schema version in Schema Registry that matches the subject name. This mode is compatible with Avro and Protobuf schemas and is used when you don't produce to the topic using the wire format.
+- `value_schema_latest`: Creates an Iceberg table whose structure matches the latest schema version in Schema Registry that matches the subject name. This mode is compatible with Avro and Protobuf schemas and is used when you don't produce to the topic using the wire format.
 - `disabled`: Disables writing to an Iceberg table for the topic.
 
-For `value_subject_latet` mode, use the following syntax:
+For `value_schema_latest` mode, use the following syntax:
 
 [,bash]
 ----
-value_subject_latest[:<key1>=<value1>,<key2>=<value2>]
+value_schema_latest[:<key1>=<value1>,<key2>=<value2>]
 ----
 
-* Only the string `value_subject_latest` is required in the property value.
+* Only the string `value_schema_latest` is required in the property value.
 * Key-value pairs as indicated by `<key>=<value>` inside the square brackets `[]` are optional. The key-value pairs override this mode's default behavior for the topic.
 ** For Protobuf data, the mode's default behavior derives the suject name using xref:manage:schema-reg/schema-id-validation.adoc#set-subject-name-strategy-per-topic[TopicNameStrategy] and deserializes records using the first message definition in the associated Protobuf schema in the Schema Registry.
 +
 --
-* Specify a different subject name using a key-value pair `subject=<subject-name>`, for example `value_subject_latest:subject=my_protobuf_schema`. 
-* Specify a different message definition using a key-value pair `protobuf_name=<message-name>`, for example `value_subject_latest:protobuf_name=com.example.manufacturing.SensorData`.
-* To specify both the subject and message definition, separate the key-value pairs with a comma, for example `value_subject_latest:protobuf_name=com.example.manufacturing.SensorData,subject=my_protobuf_schema`.
+* Specify a different subject name using a key-value pair `subject=<subject-name>`, for example `value_schema_latest:subject=my_protobuf_schema`. 
+* Specify a different message definition using a key-value pair `protobuf_name=<message-name>`, for example `value_schema_latest:protobuf_name=com.example.manufacturing.SensorData`.
+* To specify both the subject and message definition, separate the key-value pairs with a comma, for example `value_schema_latest:protobuf_name=com.example.manufacturing.SensorData,subject=my_protobuf_schema`.
 --
 ** For Avro data