After making a few tests, I found that foreign keys on MEMORY engine miss one of the checks for consistency.
To explain better, here a similar example in InnoDb
CREATE TABLE testInnoDb1 (
c1 int(11) PRIMARY KEY
) ENGINE=InnoDB;
CREATE TABLE testInnoDb2 (
c1 int(11) PRIMARY KEY,
FOREIGN KEY (c1) REFERENCES testInnoDb1(c1) ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=InnoDB;
INSERT INTO testInnoDb1 (c1) VALUES (42);
INSERT INTO testInnoDb2 (c1) VALUES (42);
-- INSERT INTO testInnoDb2 (c1) VALUES (64); -- This will fail
-- UPDATE testInnoDb2 SET c1=128; -- This will fail
And the same with MEMORY
CREATE TABLE testMem1 (
c1 int(11) PRIMARY KEY
) ENGINE=MEMORY;
CREATE TABLE testMem2 (
c1 int(11) PRIMARY KEY,
FOREIGN KEY (c1) REFERENCES testMem1(c1) ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=MEMORY;
INSERT INTO testMem1 (c1) VALUES (42);
INSERT INTO testMem2 (c1) VALUES (42);
-- INSERT INTO test2 (c1) VALUES (64); -- This will fail
UPDATE testMem2 SET c1=128; -- This should fail?
My question is: Why the update consistency is not maintained with the memory engine? Is that a bug or it is for any real reason? Any reference to a known bug for this?
As additional info, I am using for development the repository release on my Linux which is still 15.1 (5.1)
MySQL does not currently support foreign key constraint checking:
PS From 15.3 re InnoDB (which has FKs) vs MEMORY (which does not):