Docs changes for changing ENUM values of foreign key mode in VSchema

content/en/docs/18.0/user-guides/vschema-guide/advanced-vschema.md

@@ -200,6 +200,6 @@ Each keyspace can be configured to run with a different foreign key mode -
 ```json
 {
   "sharded": true,
-  "foreignKeyMode": "FK_MANAGED"
+  "foreignKeyMode": "managed"
 }
 ```

content/en/docs/18.0/user-guides/vschema-guide/foreign-keys.md

@@ -7,7 +7,7 @@ For running foreign keys in Vitess, the users have a few options. Let's explore
 
 ### Vitess Unaware of Foreign Keys
 
-Users can run Vitess such that it doesn't know about or care for the foreign key constraints existing on MySQL. To run Vitess in this mode, `foreignKeyMode` VSchema property has to be set to `FK_UNMANAGED` for the given keyspace. This is the default mode for Vitess as well.
+Users can run Vitess such that it doesn't know about or care for the foreign key constraints existing on MySQL. To run Vitess in this mode, `foreignKeyMode` VSchema property has to be set to `unmanaged` for the given keyspace. This is the default mode for Vitess as well.
 
 It is up to the users to configure the foreign keys in MySQL such that rows that are related by foreign keys end up living in the same shard.
 To this end, users can configure tables related by foreign keys to use the same shared vindex. More detail about this can be read in [shared vindexes](../shared-vindexes/#foreign-keys).
@@ -24,7 +24,7 @@ To this end, users can configure tables related by foreign keys to use the same
 Please note, that in this version of Vitess, this mode is experimental and should be used cautiously.
 {{< /info >}}
 
-Users can run Vitess such that it keeps track of all the foreign key constraints using the schema tracker. To run Vitess in this mode, `foreignKeyMode` VSchema property has to be set to `FK_MANAGED` for the given keyspace.
+Users can run Vitess such that it keeps track of all the foreign key constraints using the schema tracker. To run Vitess in this mode, `foreignKeyMode` VSchema property has to be set to `managed` for the given keyspace.
 
 In this mode, Vitess takes care of splitting up DMLs that would cause updates on a child table in a foreign key constraint. All the queries on MySQL are executed such that InnoDB doesn't end up running any updates which don't make their way into the binary log. This allows VReplication to work properly, thus relaxing one of the limitations of the previous approach.
 
@@ -38,6 +38,6 @@ For more details on what operations Vitess takes please refer to the [design doc
 
 ### Vitess Disallows Foreign Keys
 
-Users can run Vitess such that it explicitly disallows any DDL statements that try to create a foreign key constraint. To run Vitess in this mode, `foreignKeyMode` VSchema property has to be set to `FK_DISALLOW` for the given keyspace.
+Users can run Vitess such that it explicitly disallows any DDL statements that try to create a foreign key constraint. To run Vitess in this mode, `foreignKeyMode` VSchema property has to be set to `disallow` for the given keyspace.
 
 This mode is for users that don't use foreign keys and want to prevent accidentally introducing them in their schema.

content/en/docs/19.0/user-guides/vschema-guide/advanced-vschema.md

@@ -200,6 +200,6 @@ Each keyspace can be configured to run with a different foreign key mode -
 ```json
 {
   "sharded": true,
-  "foreignKeyMode": "FK_MANAGED"
+  "foreignKeyMode": "managed"
 }
 ```

content/en/docs/19.0/user-guides/vschema-guide/foreign-keys.md

@@ -7,7 +7,7 @@ For running foreign keys in Vitess, the users have a few options. Let's explore
 
 ### Vitess Unaware of Foreign Keys
 
-Users can run Vitess such that it doesn't know about or care for the foreign key constraints existing on MySQL. To run Vitess in this mode, `foreignKeyMode` VSchema property has to be set to `FK_UNMANAGED` for the given keyspace. This is the default mode for Vitess as well.
+Users can run Vitess such that it doesn't know about or care for the foreign key constraints existing on MySQL. To run Vitess in this mode, `foreignKeyMode` VSchema property has to be set to `unmanaged` for the given keyspace. This is the default mode for Vitess as well.
 
 It is up to the users to configure the foreign keys in MySQL such that rows that are related by foreign keys end up living in the same shard.
 To this end, users can configure tables related by foreign keys to use the same shared vindex. More detail about this can be read in [shared vindexes](../shared-vindexes/#foreign-keys).
@@ -24,7 +24,7 @@ To this end, users can configure tables related by foreign keys to use the same
 Please note, that in this version of Vitess, this mode is experimental and should be used cautiously.
 {{< /info >}}
 
-Users can run Vitess such that it keeps track of all the foreign key constraints using the schema tracker. To run Vitess in this mode, `foreignKeyMode` VSchema property has to be set to `FK_MANAGED` for the given keyspace.
+Users can run Vitess such that it keeps track of all the foreign key constraints using the schema tracker. To run Vitess in this mode, `foreignKeyMode` VSchema property has to be set to `managed` for the given keyspace.
 
 In this mode, Vitess takes care of splitting up DMLs that would cause updates on a child table in a foreign key constraint. All the queries on MySQL are executed such that InnoDB doesn't end up running any updates which don't make their way into the binary log. This allows VReplication to work properly, thus relaxing one of the limitations of the previous approach.
 
@@ -38,6 +38,6 @@ For more details on what operations Vitess takes please refer to the [design doc
 
 ### Vitess Disallows Foreign Keys
 
-Users can run Vitess such that it explicitly disallows any DDL statements that try to create a foreign key constraint. To run Vitess in this mode, `foreignKeyMode` VSchema property has to be set to `FK_DISALLOW` for the given keyspace.
+Users can run Vitess such that it explicitly disallows any DDL statements that try to create a foreign key constraint. To run Vitess in this mode, `foreignKeyMode` VSchema property has to be set to `disallow` for the given keyspace.
 
 This mode is for users that don't use foreign keys and want to prevent accidentally introducing them in their schema.