Вероятно, такой корявой перевод обусловлен структурой предложения. Если перестроить его как «сосна родилась в лесу» получается вполне удобоваримое «Pine was born in the woods» :)
Насколько я знаю, в MyISAM таблицах есть специальное поле, где хранится число записей, поэтому в любой момент времени мы знаем, сколько там данных, не выполняя запрос. Кроме того, в MyISAM быстро отрабатывает запрос SELECT COUNT(*).
В InnoDb количество записей оценивается на основе реальных данных в таблице. А кол-во рядов (в том же phpmyadmin, например) это приблизительные данные. И не забывайте про транзакции.
Кстати, SELECT COUNT(*) там будет работать медленно, поэтому нужно ставить WHERE и желательно по индексированному полю.
Кстати, я так и не понял, как отключить этот плагин. В настройках DM убрал все галки, связанные с интеграцией в браузеры, но и в Опере, и в ФФ плагин так и остался включенным.
Как эту заразу убить (кроме сноса всего DM)?
Как вариант: использовать PHP LockIt, зашифровав главный скрипт — повесить различные проверки и сделать привязку к домену, например. Можно еще дополнительно обработать его Zend Encoder'ом.
Тоже сталкивался со странностью суппорта Маркета.
При валидации xml они даже не пытаются нормально объяснить причину отклонения заявки. Тупо высылают тех. ответы от парсера, что-то типа «Element is not valid for content model». Если перевести эту фразу, то можно подумать о неправильности тэга или ошибки в написании. Но нет, тэг валидный и написан корректно. Направив письмо с просьбой разъяснить, выясняется, что в выдаче неправильный порядок тэгов! С каких это пор для xml стал важен порядок следования элементов?
И ведь за это люди платят деньги, а суппорт даже не может давать сразу адекватные ответы, вместо этого пересылают эксепшены с невразумительным текстом ошибки.
Если продажи и пошли вверх, то только благодаря бренду.
Разочарование года.
Разве ж это «траффик и многобукафф»? Вы недооцениваете хабрачитателя :)
В InnoDb количество записей оценивается на основе реальных данных в таблице. А кол-во рядов (в том же phpmyadmin, например) это приблизительные данные. И не забывайте про транзакции.
Кстати, SELECT COUNT(*) там будет работать медленно, поэтому нужно ставить WHERE и желательно по индексированному полю.
Ну может хотя бы «покоробил»?
Как эту заразу убить (кроме сноса всего DM)?
При валидации xml они даже не пытаются нормально объяснить причину отклонения заявки. Тупо высылают тех. ответы от парсера, что-то типа «Element is not valid for content model». Если перевести эту фразу, то можно подумать о неправильности тэга или ошибки в написании. Но нет, тэг валидный и написан корректно. Направив письмо с просьбой разъяснить, выясняется, что в выдаче неправильный порядок тэгов! С каких это пор для xml стал важен порядок следования элементов?
И ведь за это люди платят деньги, а суппорт даже не может давать сразу адекватные ответы, вместо этого пересылают эксепшены с невразумительным текстом ошибки.