Re: [Maria-developers] [Commits] Rev 3984: MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. in file:///home/hf/wmar/10-hf/
Hi, Change: Another change is that it uses the index name for the internal dictionary. Not ok. Firstly, that change should affect many test cases using foreign keys. Secondly, that would effect applications using foreign keys. I could only imagine how many and what kind of applications there are to create/drop foreign keys that are currently created with InnoDB internal foreign key names. Finally, this fix is 'correct' only for new tables, not existing tables containing foreign keys. This change would be incompatibility change to default behavior.
At file:///home/hf/wmar/10-hf/
------------------------------------------------------------ revno: 3984 revision-id: holyfoot@askmonty.org-20140205184909-9nmsj1mzwo6cka0m parent: sergii@pisem.net-20140205171851-0vax8lnwtbousucu committer: Alexey Botchkov <holyfoot@askmonty.org> branch nick: 10-hf timestamp: Wed 2014-02-05 22:49:09 +0400 message: MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. Patches for server and the Innodb engine. Server is fixed so it does nothing if no indexes left to alter. Innodb parser is fixed so it looks for the IF [NOT] EXISTS option in a string. Another change is that it uses the index name for the internal dictionary. Prior to that it only used the CONSTRAINT name for it.
_______________________________________________ commits mailing list commits@mariadb.org https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits
-- -- Jan Lindström Principal Engineer MariaDB | MaxScale | skype: jan_p_lindstrom www.skysql.com <http://www.skysql.com/> Twitter <http://twitter.com/skysql> Blog <http://www.skysql.com/blog/> Facebook <http://www.facebook.com/skysql> LinkedIn <http://www.linkedin.com/company/1214250> Google+ <https://plus.google.com/117544963211695643458/posts>
Hi, Jan! On Feb 06, Jan Lindström wrote:
Hi,
Change: Another change is that it uses the index name for the internal dictionary.
Not ok. Firstly, that change should affect many test cases using foreign keys.
Not many, only two: innodb.innodb_information_schema and rpl.rpl_mdev382. I've fixed that already.
Secondly, that would effect applications using foreign keys. I could only imagine how many and what kind of applications there are to create/drop foreign keys that are currently created with InnoDB internal foreign key names. Finally, this fix is 'correct' only for new tables, not existing tables containing foreign keys. This change would be incompatibility change to default behavior.
I don't think that matters. InnoDB foreign key names were auto-generated. An application would need to use SHOW commands or select from information_schema tables to find foreign key names. This haven't changed. Any application that used SHOW commands or information_schema tables to find foreign key names will continue to work. One can still think of all foreign key names as "generated". Only the name generation algorithm has changed. Similarly, it is logical, that the old foreign key names were not changed - this is, again, only a change in the name generation algorithm, it only affect new tables.
At file:///home/hf/wmar/10-hf/
------------------------------------------------------------ revno: 3984 revision-id: holyfoot@askmonty.org-20140205184909-9nmsj1mzwo6cka0m parent: sergii@pisem.net-20140205171851-0vax8lnwtbousucu committer: Alexey Botchkov <holyfoot@askmonty.org> branch nick: 10-hf timestamp: Wed 2014-02-05 22:49:09 +0400 message: MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. Patches for server and the Innodb engine. Server is fixed so it does nothing if no indexes left to alter. Innodb parser is fixed so it looks for the IF [NOT] EXISTS option in a string. Another change is that it uses the index name for the internal dictionary. Prior to that it only used the CONSTRAINT name for it.
Regards, Sergei
Hi, I agree all other points except the fact that you do not need to use SHOW commands. Applications might rely on fact that internal foreign key names on InnoDB are form <table_name>_ibfk_<n>. But maybe this is only a minor 'matter'. Current, patch handles only InnoDB part not XtraDB, these should work similarly, to avoid confusion.
Hi, Jan!
On Feb 06, Jan Lindström wrote:
Hi,
Change: Another change is that it uses the index name for the internal dictionary.
Not ok. Firstly, that change should affect many test cases using foreign keys. Not many, only two: innodb.innodb_information_schema and rpl.rpl_mdev382. I've fixed that already. Good, strange that there is so few affected.
Secondly, that would effect applications using foreign keys. I could only imagine how many and what kind of applications there are to create/drop foreign keys that are currently created with InnoDB internal foreign key names. Finally, this fix is 'correct' only for new tables, not existing tables containing foreign keys. This change would be incompatibility change to default behavior. I don't think that matters. InnoDB foreign key names were auto-generated. An application would need to use SHOW commands or select from information_schema tables to find foreign key names.
This haven't changed. Any application that used SHOW commands or information_schema tables to find foreign key names will continue to work. One can still think of all foreign key names as "generated". Only the name generation algorithm has changed.
Similarly, it is logical, that the old foreign key names were not changed - this is, again, only a change in the name generation algorithm, it only affect new tables.
At file:///home/hf/wmar/10-hf/
------------------------------------------------------------ revno: 3984 revision-id: holyfoot@askmonty.org-20140205184909-9nmsj1mzwo6cka0m parent: sergii@pisem.net-20140205171851-0vax8lnwtbousucu committer: Alexey Botchkov <holyfoot@askmonty.org> branch nick: 10-hf timestamp: Wed 2014-02-05 22:49:09 +0400 message: MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. Patches for server and the Innodb engine. Server is fixed so it does nothing if no indexes left to alter. Innodb parser is fixed so it looks for the IF [NOT] EXISTS option in a string. Another change is that it uses the index name for the internal dictionary. Prior to that it only used the CONSTRAINT name for it. Regards, Sergei
R: -- Jan Lindström Principal Engineer MariaDB | MaxScale | skype: jan_p_lindstrom www.skysql.com <http://www.skysql.com/> Twitter <http://twitter.com/skysql> Blog <http://www.skysql.com/blog/> Facebook <http://www.facebook.com/skysql> LinkedIn <http://www.linkedin.com/company/1214250> Google+ <https://plus.google.com/117544963211695643458/posts>
Hi, Jan! On Feb 06, Jan Lindström wrote:
Hi,
I agree all other points except the fact that you do not need to use SHOW commands. Applications might rely on fact that internal foreign key names on InnoDB are form <table_name>_ibfk_<n>. But maybe this is only a minor 'matter'. Current, patch handles only InnoDB part not XtraDB, these should work similarly, to avoid confusion.
Yes, I've fixed this too when I fixed test cases (because we run many tests for innodb and xtradb with the same result file, so any difference shows up). Thanks, Jan! I take it that you no longer oppose this change, and I'll push it today. Regards, Sergei
participants (2)
-
Jan Lindström -
Sergei Golubchik