Foreign key on update action with non literal values

[harshit-gangal]

Description

This PR adds support for foreign key on update action when the referenced value is non-literal.
eg: update tbl set fk_col = cola + colb where id = 100.

Planning is augmented to support this use case. We also had to change the FkCascade engine to add this functionality. For the case of non-literal updates, we have to propagate the cascades by going over each row one by one since the value that each row is updated to could be different for each one.

As part of this PR, the fuzzer has also been augmented to produce queries with complex expressions to make sure everything works as intended.

We still have one limitation after this PR wherein we cannot support column updates for foreign keys such that it depends on some other column that is also being updated. For example, consider the query update u_tbl3 set cola = id, colb = 5 * (cola + (1 - (cola))) where id = 2 where colb is part of a foreign key constraint. In this case, we cannot safely run this query in Vitess while propagating all the cascade operations. Therefore, we have chosen to fail queries like these.

We cannot support updating a foreign key column that is using a column that is also being updated for 2 reasons—

1. For the child foreign keys, we aren't sure what the final value of the updated foreign key column will be. So we don't know what to cascade to the child. The selection that we do isn't enough to know if the updated value since one of the columns used in the update is also being updated.
2. For the parent foreign keys, we don't know if we need to reject this update. Because we don't know the final updated value, the update might need to be failed, but we can't say for certain.

Post these changes, we are able to support non-literal updates to foreign key columns (barring the limitation listed above). An example plan for such a plan looks like -

{
  "QueryType": "UPDATE",
  "Original": "update parent set col = id + 2",
  "Instructions": {
    "OperatorType": "FkCascade",
    "Inputs": [
      {
        "InputName": "Selection",
        "OperatorType": "Route",
        "Variant": "Unsharded",
        "Keyspace": {
          "Name": "unsharded_fk_allow",
          "Sharded": false
        },
        "FieldQuery": "select col, col != id + 2, id + 2 from parent where 1 != 1",
        "Query": "select col, col != id + 2, id + 2 from parent for update",
        "Table": "parent"
      },
      {
        "InputName": "CascadeChild-1",
        "OperatorType": "Update",
        "Variant": "Unsharded",
        "Keyspace": {
          "Name": "unsharded_fk_allow",
          "Sharded": false
        },
        "TargetTabletType": "PRIMARY",
        "BvName": "fkc_vals",
        "Cols": [
          0
        ],
        "CompExprCols": [
          1
        ],
        "Query": "update /*+ SET_VAR(foreign_key_checks=OFF) */ child set col = :fkc_upd where (col) in ::fkc_vals",
        "Table": "child",
        "UpdateExprBvNames": [
          "fkc_upd"
        ],
        "UpdateExprCols": [
          2
        ]
      },
      {
        "InputName": "Parent",
        "OperatorType": "Update",
        "Variant": "Unsharded",
        "Keyspace": {
          "Name": "unsharded_fk_allow",
          "Sharded": false
        },
        "TargetTabletType": "PRIMARY",
        "Query": "update /*+ SET_VAR(foreign_key_checks=OFF) */ parent set col = id + 2",
        "Table": "parent"
      }
    ]
  },
  "TablesUsed": [
    "unsharded_fk_allow.child",
    "unsharded_fk_allow.parent"
  ]
}

Related Issue(s)

• RFC: Foreign Key Support in Vitess #12967

Checklist

• Tests were added or are not required
• Did the new or modified tests pass consistently locally and on the CI

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• Ensure there is a link to an issue (except for internal cleanup and flaky test fixes), new features should have an RFC that documents use cases and test cases.

Tests

• Bug fixes should have at least one unit or end-to-end test, enhancement and new features should have a sufficient number of tests.

Documentation

• Apply the release notes (needs details) label if users need to know about this change.
• New features should be documented.
• There should be some code comments as to why things are implemented the way they are.
• There should be a comment at the top of each new or modified test to explain what the test does.

New flags

• Is this flag really necessary?
• Flag names must be clear and intuitive, use dashes (-), and have a clear help text.

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow needs to be marked as required, the maintainer team must be notified.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from vitess-operator and arewefastyet, if used there.
• vtctl command output order should be stable and awk-able.

[GuptaManan100]

@harshit-gangal Could you review it again please 🥺 ?

[harshit-gangal]

LGTM

[GuptaManan100]

Approving on Harshit's behalf.