Hi! InnoDB is a MySQL table type which provides transactions, row-level locking, foreign key constraints, and a non-free hot backup tool for backing up InnoDB tables.
InnoDB is included in all MySQL-4.0, 4.1, and 5.0 downloads, and also in the MySQL Pro commercial, non-GPL MySQL license. Release 4.0.18 is mainly a bugfix release, but there are some functional changes in FOREIGN KEY handling as well. The full changelog: * Do not allow dropping a table referenced by a FOREIGN KEY constraint, unless the user does SET FOREIGN_KEY_CHECKS=0. The error message here is somewhat misleading 'Cannot delete or update a parent row...', and must be changed in a future version 4.1.x. * Make InnoDB to remember the CONSTRAINT name given by a user to a FOREIGN KEY. * Change print format of FOREIGN KEY constraints spanning multiple databases to <backquote>databasename<backquote>.<backquote>tablename<backquote>. But when parsing them we must also accept <backquote>databasename.tablename<backquote>, because that was the output format in < 4.0.18. * An optimization in locking: if AUTOCOMMIT=1, then we do not need to make a plain SELECT set shared locks even on the SERIALIZABLE isolation level, because we know the transaction is read-only: a read-only transaction can always be performed on the REPEATABLE READ level, and that does not endanger the serializability. * Implement an automatic downgrade from >= 4.1.1 -> 4.0.18 if the user has not created tables in .ibd files or used other 4.1.x features. CONSULT the manual section http://www.innodb.com/ibman.php#Multiple.tablespaces carefully if you want to downgrade! * Fixed a bug: MySQL should not let REPLACE to perform internally an UPDATE if the table is referenced by a FOREIGN KEY. The MySQL manual says that REPLACE must resolve a duplicate key error semantically with DELETE(s) + INSERT, and not by an UPDATE. In versions < 4.0.18 and < 4.1.2 MySQL could resolve a duplicate key conflict in REPLACE by doing an UPDATE on the existing row, and FOREIGN KEY checks could behave in a semantically wrong way. (Bug #2418) * Fixed a bug: generate foreign key identifiers locally for each table, in the form 'databasename/tablename_ibfk_number'. If the user gives the constraint name explicitly, then remember it. These changes should ensure that foreign key id's in a slave are the same as in the master, and DROP FOREIGN KEY does not break replication. (Bug #2167) * Fixed a bug: allow quoting of identifiers in InnoDB's FOREIGN KEY definitions with backquote (`) and double quote ("). You can now use also spaces in table and column names, if you quote the identifiers. (Bug #1725) (Bug #2424) * Fixed a bug: FOREIGN KEY ... ON UPDATE/DELETE NO ACTION must check the foreign key constraint, not ignore it. Since we do not have defered constraints in InnoDB, this bug fix makes InnoDB to check NO ACTION constraints immediately, like it checks RESTRICT constraints. * Fixed a bug: InnoDB crashed in RENAME TABLE if 'databasename.tablename' is shorter than 5 characters. (Bug #2689) * Fixed a bug: InnoDB row count and index cardinality estimates wrapped around at 512 million in 32-bit computers. Note that unless MySQL is compiled with the BIG_TABLES option, they will still wrpa around at 4 billion. * Fixed a bug: with InnoDB, UNIQUE secondary index, and NULL values in that unique index; with the IS NULL predicate, InnoDB returned only the first matching row, though there can be many. This bug was introduced in 4.0.16. (Bug #2483) Best regards, Heikki Tuuri Innobase Oy http://www.innodb.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
