Bug #37124
closed
db-compare should check for available storage-engines
Added by Stefan Neufeind over 12 years ago.
Updated about 6 years ago.
Category:
Database API (Doctrine DBAL)
Description
Currently if you have MySQL with, for example, disabled InnoDB (for reasons out of scope of this ticket) db-compare will insist that db-changes are needed. But that storage-engine can't be set since it is not available. So for the easy case TYPO3 might still want to leave it as is (MyISAM in the usual case).
Example:
ALTER TABLE tx_realurl_pathcache ENGINE=InnoDB;
Current value: ENGINE=MyISAM
ALTER TABLE tx_realurl_chashcache ENGINE=InnoDB;
Current value: ENGINE=MyISAM
ALTER TABLE tx_realurl_urldecodecache ENGINE=InnoDB;
Current value: ENGINE=MyISAM
ALTER TABLE tx_realurl_urlencodecache ENGINE=InnoDB;
Current value: ENGINE=MyISAM
Also applies to all other branches. Also tested with 4.7.
In my opinion we should write a note in INSTALL.txt about usage of InnoDB in the core. Something like: Be aware that TYPO3 uses the InnoDB storage engine on certain tables. Please make sure to have InnoDB available. If you for some reason have no InnoDB available TYPO3 will probably still work, but there could be some side effects.
(Also because making it optional would mean we should test performance, locking etc with both storage engines all the time, and that does not make sense).
What do you think?
I think we could add a warning in install-tool and/or db-analyser that expresses TYPO3 might still work but it's recommended to enable InnoDB.
For performance I don't think we should really care, if we give that "warning".
Do we do much locking anyway? (I just don't know.) I was under the impression that due to being SQL-portable as possible (DBAL, ...) we don't do much in that department yet. How would MySQL behave if you tell it to lock but MyISAM can't do that (missing support for transactions)?
My intention was just that I think the thing about "oh, I've found an update - you should turn on InnoDB" and if you do it it comes back with "and how about InnoDB" is ... suboptimal.
Please keep in mind that on some hosting providers you're simply not able to turn on InnoDB or you have to pay extra money.
For small sites it doesn't make much of a difference if InnoDB is not available, but the storage engine warnings are quite annoying.
I think placing a textual warning in the install tool would suffice and by adding the check for available storage engine we get much more usability.
(Just to write it here once: These warnings also show up, whenever one uses the Database Update tab of extensions, which is also really annoying.)
- Status changed from New to Needs Feedback
- Is Regression set to No
Is this still an issue?
I never had the case that InnoDB was disabled, so I need to ask ;-)
A big hoster in Austria has InnoDB disabled by default. Extra money to pay to get it.
Still an issue, of course. Also happens if you setup a small dev-system and disable InnoDB to save diskspace or so.
Related there is a review in #61132 to allow overriding storage-engines. Should we assume that InnoDB is "usually" available, so abandon this here, and continue in the other issue whether we want to have a "expert-setting" to override storage-engines?
Another thought: If we really demand InnoDB, maybe installer/environment-check should try to find out if InnoDB is available. We could add such a check as part of this issue here imho, if the resolution is that InnoDB is mandatory.
Lolli just confirmed that we should have (add?) InnoDB as a hard requirement today. So maybe we just need to add that to the requirements and environment-checks.
What is the state of this issue?
Guys. Did something changed in this topic? My hosting provider disabled InnoDB because of some CPanel related issues. Now I can't finish TYPO3 update to 6.2.12.
@Tomasz:
- From which version do you upgrade from?
- Where does it stop/break/fail?
@Stefan: So we should add a test for available storage engines on MySQL?
- Category set to Database API (Doctrine DBAL)
- Status changed from Needs Feedback to New
- Target version set to Candidate for patchlevel
- Status changed from New to Under Review
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Closed
Also available in: Atom
PDF