Hi,
I've noticed that while installing Virtuemart forces MyISAM tables (while joomla itself does not)
Why is it set? Normaly the database admin tells what type to use and there is only one reason to set MyISAM. Only if you use Fulltext search. In all other cases you should not set the type.
But it gets worse: It seems MyISAM is set everytime the configuration is stored.
Since we run Joomla and virtuemart on loadbalanced hosting we need innodb.
Could you please use the way Joomla sets the table type (i think it is NOT set the type) but definitly not set the type after stuff is installed.
"Only if you use Fulltext search."
Nonsense, the field is a lot complexer and I gave up to talk with people about it who did not read at least 20 hours about. Really.
Hi Milbo,
Thanks for your reaction. We do appreciate Virtuemart. It it getting a real sollid shop. More customers are using it on our loadbalanced webhosting platform.
But could you not set MyISAM every time de configuration is saved?
"And I gave up to talk with people about it who did not read at least 20 hours about"
That's fine, i understand, So lets talk about it...
So to save you a lot of typing: could you hint with keywords in what direction you think the problems with innodb would appear or what problems you would get while not using MyISAM?
This article sums up why it is not needed: http://dbahire.com/today-is-the-day-in-which-myisam-is-no-longer-needed/
I mean, The Joomla developers don't seem to have any issues (Joomla does not set the type) and we are running Wordpress, Joomla with RS forms, Hikashop, Jreviews and, of course, Virtuemart with InnoDB without any problems on an loadbalanced platform. All of them run just fine and fast.
So please hint us why you think MyISAM has to be forced?
In short:
"... The 5.7.5 "Milestone 15" release, presented today at the Oracle Open World has an impressive list of changes, which I will need some time to digest, like an in-development (syncronous?) multi-master replication or a revamped query optimizer. But the one very change that I want to highlight today is how the last one of the "big 3" reasons to use MyISAM has finally vanished. For me (and my customers) those reasons were:"
Mysql 5.7.5, before the author says himself it makes still sense to use MYISAM. Thank you for the article, I will read it.
I add an hidden config updEngine http://docs.virtuemart.net/manual/general-concepts/206-hidden-configurations.html
Please try http://dev.virtuemart.net/attachments/download/976/com_virtuemart.3.0.11.4_extract_first.zip
Thanks Milbo,
It did not help. But maybe i did not do it right.
I added updEngine=False (and tried false, FALSE to) to the virteumeart.cfg
Checked if it loaded en the setting was not overwritten.
i installed 3.0.12
Or did the file you pointed out contain a fix that is not in 3.0.12. In that case, it make sense that it did not work
i checked and line 678 in http://dev.virtuemart.net/projects/virtuemart/repository/revisions/9033/entry/trunk/virtuemart/administrator/components/com_virtuemart/helpers/tableupdater.php is there.
When storing the settings the following tables are converted to MyISAM
xx_virtuemart_vendors_nl_nl
xx_virtuemart_shipmentmethods_nl_nl
xx_virtuemart_products_nl_nl
xx_virtuemart_paymentmethods_nl_nl
xx_virtuemart_manufacturers_nl_nl
xx_virtuemart_manufacturercategories_nl_nl
xx_virtuemart_categories_nl_nl
Updating to VM 3.0.12 converted all VM tables to MyISAM BTW.
Quote from: ronaldotto on November 11, 2015, 14:11:53 PM
I added updEngine=False (and tried false, FALSE to) to the virteumeart.cfg
You must store your virtuemart config. I mean not ONLY the virtuemart.cfg, also in the BE. So that the file is loaded and the value becomes part of the loaded config.
The following loop tried several times:
The BE said: Loaded Config and stored config.
Changed the mentioned tables directly to MyISAM.
So i changed it back with PhpMyadmin.
Went to the BE and clicked store and the BE said: Loaded Config and stored config.
Tables were converted to MyISAM.
hmmm, okey, sry, then I have to take another look.