Repository navigation
Conversation
Creating models or adding fields with column-level check constraints (such as positive integer fields) previously produced invalid Spanner SQL in several ways: - Constraint names interpolated the quoted field name inside an unquoted identifier, embedding backticks in the middle of the name whenever the field needed quoting, while leaving the table name unquoted. - Check expressions referenced the column name without quoting, breaking columns named after reserved keywords or containing special characters. - Adding a field with a check constraint appended the constraint inline to the ADD COLUMN statement, which Spanner does not allow. This change fixes these issues by: - Generating deterministic check constraint names using Django's standard naming convention, sanitizing dots, respecting Spanner's identifier length limit, and quoting the full constraint name as a single identifier. - Quoting column names inside generated check constraint expressions. - Issuing a separate ALTER TABLE ... ADD CONSTRAINT statement when adding a field with a check constraint. - Adding unit tests covering reserved-keyword columns, special characters in table names, unconditional identifier quoting, custom database column names, long dotted names, column renames, and adding fields across all positive integer field types.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the Django Google Spanner backend to use deterministic check constraint names and handles adding check constraints separately when adding new fields, as Spanner does not support inline constraints during column additions. It also adds comprehensive unit tests for these changes. The reviewer feedback points out that Cloud Spanner does not allow renaming columns referenced by check constraints. To prevent database errors, the reviewer suggests overriding _rename_field to drop the old check constraint before renaming and recreate it afterward, and updating the corresponding test to assert this drop-and-recreate behavior.
|
The build failures should be auto-fixed once #19069 has been merged and this PR has been rebased. |
Creating models or adding fields with column-level check constraints (such as positive integer fields) previously produced invalid Spanner SQL in several ways:
This change fixes these issues by: