Новый метод (очистка мультизапроса) вызвал неожиданные трудности

Оказалось, что крайне полезный метод clear_multiresult($result), о котором было написано здесь, не работает. 


Поиск проблемы был трудный и интересный. Не могу не написать об этом.

Как известно (из документации), метод $mysqli->multi_query() создает в процессе выполнения набор результатов по одному для каждого запроса, входящего в мультизапрос.

Для того, чтобы эти запросы вытаскивать на свет Божий и обрабатывать существуют 3 замечательных метода:

• $mysqli->store_result()
• $mysqli->next_result()
• $mysqli->more_results() 

Кому интересны подробности - прошу обратиться к документации.

Скажу только, что загвоздка оказалась в методе $mysqli->next_result().

Предположим, у нас есть мультизапрос, состоящий из 4-х запросов. Причем в третьем запросе ошибка. Тогда мы будем действовать  следующим образом.

• Выполним $mysqli->store_result(). Этим мы вытащим из недр API результат первого запроса.
• Обработали результат и удалили его.
• Выполняем подготовку второго запроса методом  $mysqli->next_result(). При этом метод вернет TRUE, что и ожидалось.
• Выполним $mysqli->store_result(). Этим мы вытащим из недр API результат второго запроса.
• Обработали результат и удалили его.
• Выполняем подготовку третьего запроса методом  $mysqli->next_result(). При этом метод вернет FALSE, что абсолютно не ожидалось. При этом в документации черным по белому написано, что метод возвращает истину, если метод выполнился удачно, и ложь, если операция потерпела неудачу. Какая же тут неудача? Все вполне удачно, поскольку если не обращать внимания на возвращаемое значение метода, ошибочный результат все-таки подготавливается и можно двигаться дальше, то есть проверять на ошибки и тд и тп.
• Не обращаем внимания на возвращаемое значение и выполняем $mysqli->store_result(). Этим мы вытащим из недр API результат второго запроса.
• Обработали результат, то есть проверили его на ошибки, выявили ошибку и выполнили my_exit();

А как же проверять тот факт, что результаты кончились? Конечно методом $mysqli->more_results(). Он для этого и создан.

Новый метод в классе EMYSQL

Класс EMYSQL позволяет выполнять мультизапросы. Это такая строка, которая состоит из нескольких запросов MYSQL, разделенными точкой с запятой.
После такого запроса в недрах MySQL рождается результат, состоящий из результатов каждого запроса, входящего в мультизапрос. Даже если мультизапрос состоял из запросов, которые не должны возвращать результат, результат все равно будет не пуст. Нужно очистить этот результат, обратившись к каждому результату по отдельности.
Добавлен метод clear_multiresult($result), который очищает результат мультизапроса, точнее все результаты запросов, входящих в мультизапрос.

Временная таблица имен файлов для парсинга

CREATE TABLE IF NOT EXISTS `tbl_parsefile` (
  `parsefile_id` int(6) NOT NULL AUTO_INCREMENT COMMENT 'Первичный ключ',
  `parsefile_file` varchar(250) NOT NULL DEFAULT '' COMMENT 'Имя файла с путем',
  `parsefile_code` tinyint(2) NOT NULL DEFAULT '0' COMMENT 'Числовая категория файла',
  `parsefile_tcode` varchar(20) NOT NULL COMMENT 'Текстовая категория файла',
  PRIMARY KEY (`parsefile_id`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 COMMENT='Временная таблица файлов для парсинга' AUTO_INCREMENT=1 ;


Коды:
1 (SS_TABUPLOAD::PACKAGE_PAGE) - файл проекта. tcode - название проекта
2 (SS_TABUPLOAD::FILE_PAGE) - файл файла проекта. tcode - название файла

Таблица для учета подпроектов (категорий)

--
-- Структура таблицы `tbl_subpack`
--

CREATE TABLE IF NOT EXISTS `tbl_subpack` (
  `subpack_id` int(6) NOT NULL AUTO_INCREMENT COMMENT 'Первичный ключ',
  `subpack_pack` int(6) NOT NULL COMMENT 'Ссылка на package',
  `subpack_name` varchar(30) NOT NULL DEFAULT '' COMMENT 'Название категории',
  `subpack_longdescr` text NOT NULL COMMENT 'Длинное описание категории',
  PRIMARY KEY (`subpack_id`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 COMMENT='Категории каждого проекта' AUTO_INCREMENT=1 ;

Таблица для учета проектов

--
-- Структура таблицы `tbl_pack`
--

CREATE TABLE IF NOT EXISTS `tbl_pack` (
  `pack_id` int(6) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Первичный ключ',
  `pack_name` varchar(50) NOT NULL COMMENT 'Название проекта (documentor)',
  `pack_descr` varchar(50) NOT NULL COMMENT 'Более длинное название проекта (русский язык)',
  `pack_npp` int(6) unsigned NOT NULL DEFAULT '0' COMMENT 'Номер для сортировки (для будущих версий)',
  `pack_longdescr` text NOT NULL COMMENT 'Длинное HTML описание проекта',
  PRIMARY KEY (`pack_id`),
  KEY `pack_npp` (`pack_npp`)
) ENGINE=MyISAM  DEFAULT CHARSET=cp1251 COMMENT='Проекты php (packages)' AUTO_INCREMENT=5 ;

Изменения в плане обработки ошибочных ситуаций

При здравом взгляде, оказалось, что практически все ошибки, который возникают в классах EMYSQL, HUP и CRYPT являются фатальными и нет никакого смысла при их возникновении продолжать работу скрипта. Поэтому вместо того, чтобы запоминать код ошибки в свойстве $err_no, громное большинство таких ошибок заменены на вызов функции my_exit().

Новое свойство $hup_common в классе BASE_CHECK

Введено новое $hup_common свойство в классе BASE_CHECK.
Изменен текст метода set_unexpected() в классе BASE_CHECK.

Подробности здесь.