Rename Foreign Key enum values in VSchema and drop FK_ prefix (#14274)

Signed-off-by: Manan Gupta <[email protected]>

Author: GuptaManan100

changelog/18.0/18.0.0/release_notes.md

@@ -85,14 +85,14 @@ It is disabled by default.
 A new field `foreignKeyMode` has been added to the VSchema. This field can be provided for each keyspace. The VTGate flag `--foreign_key_mode` has been deprecated in favour of this field.
 
 There are 3 foreign key modes now supported in Vitess -
-1. `FK_UNMANAGED` -
+1. `unmanaged` -
    This mode represents the default behaviour in Vitess, where it does not manage foreign keys column references. Users are responsible for configuring foreign keys in MySQL in such a way that related rows, as determined by foreign keys, reside within the same shard.
-2. `FK_MANAGED` [EXPERIMENTAL] -
+2. `managed` [EXPERIMENTAL] -
    In this experimental mode, Vitess is fully aware of foreign key relationships and actively tracks foreign key constraints using the schema tracker. Vitess takes charge of handling DML operations with foreign keys cascading updates, deletes and verifying restrict. It will also validate parent row existence.
    This ensures that all the operations are logged in binary logs, unlike MySQL implementation of foreign keys.
    This enables seamless integration of VReplication with foreign keys.
    For more details on what operations Vitess takes please refer to the [design document for foreign keys](https://github.com/vitessio/vitess/issues/12967).
-3. `FK_DISALLOW` -
+3. `disallow` -
    In this mode Vitess explicitly disallows any DDL statements that try to create a foreign key constraint. This mode is equivalent to running VTGate with the flag `--foreign_key_mode=disallow`.
 
 #### Upgrade process

changelog/18.0/18.0.0/summary.md

@@ -85,14 +85,14 @@ It is disabled by default.
 A new field `foreignKeyMode` has been added to the VSchema. This field can be provided for each keyspace. The VTGate flag `--foreign_key_mode` has been deprecated in favour of this field.
 
 There are 3 foreign key modes now supported in Vitess -
-1. `FK_UNMANAGED` -
+1. `unmanaged` -
    This mode represents the default behaviour in Vitess, where it does not manage foreign keys column references. Users are responsible for configuring foreign keys in MySQL in such a way that related rows, as determined by foreign keys, reside within the same shard.
-2. `FK_MANAGED` [EXPERIMENTAL] -
+2. `managed` [EXPERIMENTAL] -
    In this experimental mode, Vitess is fully aware of foreign key relationships and actively tracks foreign key constraints using the schema tracker. Vitess takes charge of handling DML operations with foreign keys cascading updates, deletes and verifying restrict. It will also validate parent row existence.
    This ensures that all the operations are logged in binary logs, unlike MySQL implementation of foreign keys.
    This enables seamless integration of VReplication with foreign keys.
    For more details on what operations Vitess takes please refer to the [design document for foreign keys](https://github.com/vitessio/vitess/issues/12967).
-3. `FK_DISALLOW` -
+3. `disallow` -
    In this mode Vitess explicitly disallows any DDL statements that try to create a foreign key constraint. This mode is equivalent to running VTGate with the flag `--foreign_key_mode=disallow`.
 
 #### Upgrade process

go/test/endtoend/vtgate/foreignkey/sharded_vschema.json

@@ -1,6 +1,6 @@
 {
   "sharded": true,
-  "foreignKeyMode": "FK_MANAGED",
+  "foreignKeyMode": "managed",
   "vindexes": {
     "xxhash": {
       "type": "xxhash"

go/test/endtoend/vtgate/foreignkey/stress/fk_stress_test.go

@@ -323,7 +323,7 @@ func TestMain(m *testing.M) {
 			Name: keyspaceName,
 			VSchema: `{
 				"sharded": false,
-				"foreignKeyMode": "FK_MANAGED"
+				"foreignKeyMode": "managed"
 			}`,
 		}
 

go/test/endtoend/vtgate/foreignkey/unsharded_vschema.json

@@ -1,6 +1,6 @@
 {
   "sharded": false,
-  "foreignKeyMode": "FK_MANAGED",
+  "foreignKeyMode": "managed",
   "tables": {
     "u_t1": {},
     "u_t2": {},

go/test/vschemawrapper/vschema_wrapper.go

@@ -129,8 +129,8 @@ func (vw *VSchemaWrapper) PlannerWarning(_ string) {
 }
 
 func (vw *VSchemaWrapper) ForeignKeyMode(keyspace string) (vschemapb.Keyspace_ForeignKeyMode, error) {
-	defaultFkMode := vschemapb.Keyspace_FK_UNMANAGED
-	if vw.V.Keyspaces[keyspace] != nil && vw.V.Keyspaces[keyspace].ForeignKeyMode != vschemapb.Keyspace_FK_DEFAULT {
+	defaultFkMode := vschemapb.Keyspace_unmanaged
+	if vw.V.Keyspaces[keyspace] != nil && vw.V.Keyspaces[keyspace].ForeignKeyMode != vschemapb.Keyspace_unspecified {
 		return vw.V.Keyspaces[keyspace].ForeignKeyMode, nil
 	}
 	return defaultFkMode, nil

go/vt/proto/vschema/vschema.pb.go

@@ -57,7 +57,7 @@ func (si *declarativeSchemaInformation) ConnCollation() collations.ID {
 }
 
 func (si *declarativeSchemaInformation) ForeignKeyMode(keyspace string) (vschemapb.Keyspace_ForeignKeyMode, error) {
-	return vschemapb.Keyspace_FK_UNMANAGED, nil
+	return vschemapb.Keyspace_unmanaged, nil
 }
 
 // addTable adds a fake table with an empty column list

go/vt/schemadiff/semantics.go

@@ -155,7 +155,7 @@ func checkFKError(vschema plancontext.VSchema, ddlStatement sqlparser.DDLStateme
 	if err != nil {
 		return err
 	}
-	if fkMode == vschemapb.Keyspace_FK_DISALLOW {
+	if fkMode == vschemapb.Keyspace_disallow {
 		fk := &fkContraint{}
 		_ = sqlparser.Walk(fk.FkWalk, ddlStatement)
 		if fk.found {

go/vt/vtgate/planbuilder/ddl.go

@@ -126,7 +126,7 @@ func createOperatorFromInsert(ctx *plancontext.PlanningContext, ins *sqlparser.I
 	if err != nil {
 		return nil, err
 	}
-	if ksMode != vschemapb.Keyspace_FK_MANAGED {
+	if ksMode != vschemapb.Keyspace_managed {
 		return insOp, nil
 	}