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