View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0020357 | mantisbt | db schema | public | 2015-12-07 17:32 | 2016-06-12 00:43 |
Reporter | atrol | Assigned To | dregad | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.3.0-rc.1 | ||||
Target Version | 1.3.0-rc.2 | Fixed in Version | 1.3.0-rc.2 | ||
Summary | 0020357: Admin checks for UTF-8 collation fail | ||||
Description | Run admin/check/index.php Get Show verbose error messages gives a lot of notices like: | ||||
Tags | No tags attached. | ||||
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. Most of the 'CreateTableSQL' entries in schema.php have this parameter array('mysql', ...) might mean just mysql but not mysqli. While I am looking at it |
|
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. |
|
In this context 'mysql', refers to the underlying ADOdb data dictionary driver, which actually covers both mysql and mysqli "client" drivers.
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:
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. |
|