feat: foreign key on delete cascade

[arpan14]

• Adding integration tests for foreign key on delete cascade feature testing both GoogleSQL + PostGres dialects.
• Adding documentation samples along with integration tests for the samples.
  • Making a minor enhancement in the samples integration test setup framework to allow accepting a host URL in Spanner options to allow overriding and testing in staging env.

[snippet-bot]

Here is the summary of changes.

You are about to add 3 region tags.

• samples/snippets/src/main/java/com/example/spanner/AlterTableWithForeignKeyDeleteCascadeSample.java:19, tag spanner_alter_table_with_foreign_key_delete_cascade
• samples/snippets/src/main/java/com/example/spanner/CreateTableWithForeignKeyDeleteCascadeSample.java:19, tag spanner_create_table_with_foreign_key_delete_cascade
• samples/snippets/src/main/java/com/example/spanner/DropForeignKeyConstraintDeleteCascadeSample.java:19, tag spanner_drop_foreign_key_constraint_delete_cascade

---

This comment is generated by snippet-bot.
If you find problems with this result, please file an issue at:
https://github.com/googleapis/repo-automation-bots/issues.
To update this comment, add snippet-bot:force-run label or use the checkbox below:

• Refresh this comment

[olavloite]

Tip (no need to change it in this PR unless you want to): You can simplify many of these test transactions further if you just return the value that is returned by the batchUpdate (or any other update statement in the transaction). That again would allow you to define the whole transaction as a lambda like this:

    databaseClient
        .readWriteTransaction()
        .run(
            transaction -> transaction.executeUpdate(singerDeleteStatementWithValues));

[anuragsrivstv]

May be instead of checking the output message we should verify that the table was actually altered by the sample or not ?

[arpan14]

• Yes, for all the tests in the integration test class ITForeignKeyDeleteCascadeTest we validate/assert the foreign key constraint.
• These tests are for the samples. Samples internally use the code that is already validated through ITForeignKeyDeleteCascadeTest . Hence, we don't need to again make a database call.
• In Java, asserting output statements is a very standard practice across all existing samples. I agree, its not the best strategy but for cases like this where we have other integration tests doing deep DDL checks, I think keeping the sample tests simple is ok.