{"id":720,"date":"2009-04-13T20:05:42","date_gmt":"2009-04-13T18:05:42","guid":{"rendered":"http:\/\/code.openark.org\/blog\/?p=720"},"modified":"2009-04-13T20:06:51","modified_gmt":"2009-04-13T18:06:51","slug":"why-of-the-week","status":"publish","type":"post","link":"https:\/\/code.openark.org\/blog\/mysql\/why-of-the-week","title":{"rendered":"“Why?” of the week"},"content":{"rendered":"

As progress on oak-online-alter-table<\/a> goes on, I’m encountering more and more limitations, for which I must find workarounds. Here’s two:<\/p>\n

CREATE TABLE … LIKE …<\/h4>\n

It works well, but it doesn’t copy any foreign key constraints. So, if the original table is this:<\/p>\n

\n
CREATE TABLE `dept_emp` (\r\n  `emp_no` int(11) NOT NULL,\r\n  `dept_no` char(4) NOT NULL,\r\n  `from_date` date NOT NULL,\r\n  `to_date` date NOT NULL,\r\n  PRIMARY KEY  (`emp_no`,`dept_no`),\r\n  KEY `emp_no` (`emp_no`),\r\n  KEY `dept_no` (`dept_no`),\r\n  CONSTRAINT `dept_emp_ibfk_1` FOREIGN KEY (`emp_no`) REFERENCES `employees` (`emp_no`) ON DELETE CASCADE,\r\n  CONSTRAINT `dept_emp_ibfk_2` FOREIGN KEY (`dept_no`) REFERENCES `departments` (`dept_no`) ON DELETE CASCADE\r\n) ENGINE=InnoDB DEFAULT CHARSET=latin1<\/pre>\n<\/blockquote>\n
Then CREATE TABLE dept_emp_shadow LIKE dept_emp<\/strong> results with:<\/p>\n
\n
CREATE TABLE `dept_emp_shadow` (\r\n  `emp_no` int(11) NOT NULL,\r\n  `dept_no` char(4) NOT NULL,\r\n  `from_date` date NOT NULL,\r\n  `to_date` date NOT NULL,\r\n  PRIMARY KEY  (`emp_no`,`dept_no`),\r\n  KEY `emp_no` (`emp_no`),\r\n  KEY `dept_no` (`dept_no`)\r\n) ENGINE=InnoDB DEFAULT CHARSET=latin1<\/pre>\n<\/blockquote>\n
Why is that? Why wouldn’t the constraints be duplicated? No explanation is given in the manual, though the behavior is documented:<\/p>\n
\"<\/code>CREATE TABLE ... LIKE<\/code><\/strong> does not preserve any  DATA DIRECTORY<\/code><\/strong> or INDEX       DIRECTORY<\/code><\/strong> table options that were specified for the       original table, or any foreign key definitions.”<\/p>\n
from http:\/\/dev.mysql.com\/doc\/refman\/5.0\/en\/create-table.html<\/a><\/p><\/blockquote>\n
Sure, I can work it by hand, or write some automation script, but… so much fuss!<\/p>\n
Changing triggers in a critical section<\/h4>\n
Say you wanted to alter a trigger. There’s no ALTER TRIGGER<\/strong> statement. So you must DROP<\/strong> the trigger first, then CREATE<\/strong> a new one.<\/p>\n
Can this be done such that nothing accidentally happens in between? The following code:<\/p>\n
\n
LOCK TABLES City WRITE;\r\nDROP TRIGGER IF EXISTS City_AI;\r\nCREATE TRIGGER City_AI AFTER INSERT ON City\r\n  FOR EACH ROW SET @dummy := 17;\r\nUNLOCK TABLES;<\/pre>\n<\/blockquote>\n
Causes a deadlock. In fact, any tampering with a trigger while the table is locked causes a deadlock. This was described in bug #23713<\/a>, and has been set as fixed, although Paul DuBois notes there’s still a deadlock. (I’m running 5.0.77 on Linux x64) .<\/p>\n
There’s an explanation ([29 Nov 2007 12:42]    Bugs System) which is unsatisfactory, as I could not make of it a solution for 5.0. Perhaps a wise reader can shed light?<\/strong><\/p>\n
I’ll try to re-submit this bug. It really gets in my way…<\/p>\n","protected":false},"excerpt":{"rendered":"
As progress on oak-online-alter-table goes on, I’m encountering more and more limitations, for which I must find workarounds. Here’s two: CREATE TABLE … LIKE … It works well, but it doesn’t copy any foreign key constraints. So, if the original table is this: CREATE TABLE `dept_emp` ( `emp_no` int(11) NOT NULL, `dept_no` char(4) NOT NULL, […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"enabled":false},"version":2}},"categories":[5],"tags":[],"class_list":["post-720","post","type-post","status-publish","format-standard","hentry","category-mysql"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2bZZp-bC","_links":{"self":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/720","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/comments?post=720"}],"version-history":[{"count":9,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/720\/revisions"}],"predecessor-version":[{"id":729,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/720\/revisions\/729"}],"wp:attachment":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/media?parent=720"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/categories?post=720"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/tags?post=720"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}