Implement FOREIGN KEY constraints
#237
Conversation
JanJakes
force-pushed
the
foreign-keys
branch
2 times, most recently
from
f2ad6dd to
a61700a
Compare
JanJakes
force-pushed
the
foreign-keys
branch
from
a61700a to
1b95119
Compare
| 'CREATE TABLE `t2` (', | ||
| ' `id` int DEFAULT NULL,', | ||
| ' `t1_id` int DEFAULT NULL,', | ||
| ' CONSTRAINT `fk1` FOREIGN KEY (`t1_id`) REFERENCES `t1` (`id`) ON DELETE CASCADE', |
There was a problem hiding this comment.
Nice, I was looking for this and I'm glad to see we're testing for SHOW CREATE TABLE
|
Do we support the following FOREIGN KEY options now?
If not, let's throw when they're used. |
|
Of course the moment I submitted the comment I found unit tests for those. Lovely! |
| $this->quote_sqlite_identifier( $referential_constraint['REFERENCED_TABLE_NAME'] ), | ||
| implode( ', ', $referenced_column_names ) | ||
| ); | ||
| if ( 'NO ACTION' !== $referential_constraint['DELETE_RULE'] ) { |
There was a problem hiding this comment.
It's covered by the tests but I still want to ask – NO ACTION is the default value of DELETE_RULE even if there is no explicit ON DELETE %s, right?
There was a problem hiding this comment.
@adamziel Yes, in both MySQL and SQLite. And it never appears explicitly in the SHOW CREATE TABLE statement. It seems that it's pretty much equivalent to RESTRICT:
- In MySQL (InnoDB),
NO ACTIONandRESTRICTbehave exactly the same. - In SQLite, there is a tiny difference about the timing of the checks, but overall, they are still equivalent: https://sqlite.org/foreignkeys.html#fk_actions
There was a problem hiding this comment.
Maybe to be even more precise, we could consider translating MySQL's NO ACTION to SQLite's RESTRICT.
From MySQL docs:
A keyword from standard SQL. For InnoDB, this is equivalent to RESTRICT; the delete or update operation for the parent table is immediately rejected if there is a related foreign key value in the referenced table.
From SQLite docs:
The "RESTRICT" action means that the application is prohibited from deleting (for ON DELETE RESTRICT) or modifying (for ON UPDATE RESTRICT) a parent key when there exists one or more child keys mapped to it. The difference between the effect of a RESTRICT action and normal foreign key constraint enforcement is that the RESTRICT action processing happens as soon as the field is updated - not at the end of the current statement as it would with an immediate constraint, or at the end of the current transaction as it would with a deferred constraint. Even if the foreign key constraint it is attached to is deferred, configuring a RESTRICT action causes SQLite to return an error immediately if a parent key with dependent child keys is deleted or modified.
Sounds like it would be a tiny bit more correct, maybe.
|
This looks great, thank you @JanJakes! Feel free to merge. Tangentially, would it be easy to add support for |
Implemented in this PR:
FOREIGN KEYconstraints inCREATE TABLE.REFECENCESclause inCREATE TABLEcolumn definitions.ADD FOREIGN KEYclause inALTER TABLE.DROP FOREIGN KEYclause inALTER TABLE.DROP CONSTRAINTclause inALTER TABLE.DROP PRIMARY KEYclause inALTER TABLE.Closes #236.
Fixes #229.