Skip to content

SQLite: allow foreign_key_check for whole DB, not just a single table#2479

Merged
geelen merged 1 commit intomainfrom
glen/sql-foreign-key-check
Aug 7, 2024
Merged

SQLite: allow foreign_key_check for whole DB, not just a single table#2479
geelen merged 1 commit intomainfrom
glen/sql-foreign-key-check

Conversation

@geelen
Copy link
Copy Markdown
Contributor

@geelen geelen commented Aug 5, 2024

In response to #2471, it would be useful to allow some migrations to completely disable foreign key constraints. However, at the end of the migration, it might be important to know whether any foreign key violations remain, before setting PRAGMA foreign_keys=ON;.

This is possible by using PRAGMA foreign_key_check;, but right now we only allow that if it contains a single argument, indicating a table name. This PR allows both no-arg and single-arg forms of that pragma.

@kossnocorp
Copy link
Copy Markdown

I'm so glad to see it happening. I'm struggling with this at this very moment, and from what I see, it should help me. If it's not too hard, can you please post a comment when this reaches production? 🙏

@justin-mp
Copy link
Copy Markdown
Contributor

Out of curiosity, what was the rationale for blocking the whole-DB check?

I imagine it can be pretty expensive. Can it result in a full scan of the entire database?

@geelen
Copy link
Copy Markdown
Contributor Author

geelen commented Aug 7, 2024

I'm not sure. From looking at the code, we didn't have a NO_ARG_OR_OBJECT_NAME construct, so maybe we just defaulted to allowing OBJECT_NAME because that seems more useful?

There's nothing stopping users from enumerating all the tables and calling foreign_key_check on each, so I don't think it's worth preventing users from accessing this, but maybe @kentonv has another take?

Copy link
Copy Markdown
Member

@kentonv kentonv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it was unintentional that this was disallowed. Allowing it seems fine.

introduced here: 1a3ac57
refactored here: f4d1e54

@geelen geelen force-pushed the glen/sql-foreign-key-check branch from 4fdcf7e to 5945e55 Compare August 7, 2024 00:56
@geelen geelen merged commit c404f95 into main Aug 7, 2024
@kentonv kentonv deleted the glen/sql-foreign-key-check branch August 7, 2024 16:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants