I think this is actually 2 distinct issues. Follow-up with SYSTEM NOTICEs in 0020365.

Sorry, no time to have a deeper look at it.
Just some thoughts I had when looking at the code that might be related to the issue.

Most of the 'CreateTableSQL' entries in schema.php have this parameter
array('mysql' => 'ENGINE=MyISAM DEFAULT CHARSET=utf8', 'pgsql' => 'WITHOUT OIDS')
At least the latest new entry for api_token is missing this.
Thus the new table might be created using another engine and/or another charset than the other tables .

array('mysql', ...) might mean just mysql but not mysqli.
mysqli is our new default in master, maybe the engine and charset options are not considered.

While I am looking at it
ENGINE=MyISAM is questionable.
We should not hardcode any engine but use the setting that the database administrator uses and/or ask for the engine in installer.

ENGINE=MyISAM is questionable.
We should not hardcode any engine but use the setting that the database
administrator uses and/or ask for the engine in installer.

I agree. In fact I vaguely remember having a discussion about this before, maybe with grangeway.

InnoDB used to have issues back then, so I assume MyISAM was forced to avoid those, but now InnoDB is the default engine so it does not make sense not to use it.

Anyway this needs careful thinking and planning before we change it.

@dregad, did you get a chance to think about this one? Lets assess impact on the 1.3 stable release.

array('mysql', ...) might mean just mysql but not mysqli.

In this context 'mysql', refers to the underlying ADOdb data dictionary driver, which actually covers both mysql and mysqli "client" drivers.

did you get a chance to think about this one?

I'm actually working on a patch. I think changing the engine for new installations should be pretty straightforward and transparent. Older, upgraded installations might end up with a mix&match of MyISAM and InnoDB tables in the database which should not cause any issues but is not considered best practice.

Probably the best would be to add an admin check to detect each table's DB engine and let the admin change them after the fact.

It's also worth mentioning that InnoDB has a few limitations/drawbacks:

• no full-text search, until MySQL 5.6.4 (not an issue for us AFAICT)
• requires more tuning effort (not likely to be a problem unless the DB is very large; and not really our problem in any case - that's under the administrator's responsibility)
• shorter index length (767 chars vs 1000 in MyISAM).

The last one is a concern for us as it may lead to issues with some of our indexes, especially if we switch to utf8mb4 character set (see 0020431). Need further investigation and testing on this.

Pull request https://github.com/mantisbt/mantisbt/pull/699

In the end I merged this fix independently from PR 699, as its primary purpose is to support utf8mb4, which is not blocking for 1.3.0 release.