Всем привет!
Что-то не могу найти способ получить CHECKSUM таблиц БД, используя штатные средства API Moodle.
$DB->execute() возвращает только bool, а других средств пользовательских запросов вроде и нет?
Подскажите, кто сталкивался с подобной проблемой, pls!
(Moodle 2.8.12 PHP 5.4.45 MySQL 5.5.31 MS Windows 7)
Если не трудно, можно подробнее о гуманных способах?😊
Разрабатывается плагин, в котором используется информация о структуре теоретического материала и банка заданий на moodle-сервере. Эта информация периодически записывается в рабочих таблицах плагина. Перед тем, как осуществлять запись производится проверка наличия изменений в определенных таблицах сервера (это course_categories, course, course_sections и т.п.). Поскольку используется MySQL - есть готовое решение: проверка CHECKSUM нужных таблиц. Но, как оказалось, применить его через API moodle, невозможно. Тогда остается либо считывать CHECKSUM в обход API, либо применять другие методы контроля наличия изменений в таблицах сервера. Был бы благодарен за наводку на оные.
ЗЫ. Кстати, phpmyadmin дает единицы миллисекунд на оценку CHECKSUM проверяемых таблиц. Думаю, даже если бы затраты составляли единицы секунд, это было бы не критично для работы сервера, поскольку данные проверки должны происходить с периодом в неделю, а то и в месяц.
Ваше решение с checksum всё-равно неправильное для многопоточной системы.
Если вам нужно гарантировать отсутствие изменений в рамках одного процесса, сам нужно использовать транзакцию и shared lock для тех строк, которые не должны поменяться и lock for update для тех строк, которые должны поменяться. В этом случае никакие другие процессы не смогут ничего изменить никакие строки до окончания вашей транзакции, а значит и целостность данных будет обеспечена.
Если вам нужно гарантировать отсутствие изменений при нескольких процессах (например, что значения до отправки формы и после отправки формы обратно на сервер совпадали), нужно вычислять контрольные значения только по тем строкам, которые вы затрагиваете, а не по всем таблицам. Иначе может возникнуть следующая ситуация. Вы вычислили контрольную сумму таблицы. В это время какой-то преподаватель начал редактировать свой курс, переименовал название раздела. При этом это может произойти в курсе, который не имеет к вашему плагину никакого отношения. В результате у вас контрольная сумма не сойдется. А mysql не умеет вычислять контрольную сумму по отдельным строкам (как функция в mssql, про которую писал Виталий).
Если вы думаете, что можно создать в moodle систему, в которой контент будет управляться только автоматически, и всегда будет полностью соответствовать неким внешним данным, то это утопия. Опыт показывает, что со временем всегда появятся дополнительные курсы для служебного назначения, какие-то курсы, где что-то будет правиться вручную, а из-за этого подход с контрольными суммами по всей таблице будет не жизненным.
Как вариант, в вашем плагине подписаться на события изменения курсов/категорий/секций, и при их возникновении сверять только отдельные элементы структуры.
Пока из вашего описания не понял, к какому из перечисленных вариантов ближе ваша ситуация.
Данная процедура не будет происходить слишком часто, например, раз в неделю или в месяц. Разве критично для работы веб-сайта, если раз в месяц в определенное время он на десяток минут будет недоступен по техническим причинам. Даже банки такое практикуют)) При таком режиме никаких конфликтов происходить не может и решение с checksum вполне сгодится. Разве нет? После определения таблиц, претерпевших изменение, происходит анализ их содержимого, удовлетворяющего заданным условиям, но это уже осуществляется в соответствии с API moodle и не должно мешать текущей работе сайта.
Вполне допускаю, что в процессе реализации что-то вылезет, но пока оставлю с checksum-ом. Как пишут отцы-основатели: Moodle не сразу строилась.
Да, это вполне приемлемый подход. Возможно, так в конечном итоге и будет. Особенность разрабатываемого сайта в том, что теоретический материал подчиняется строгой иерархии. Это означает, что таблицы верхних уровней иерархии меняются значительно реже, чем таблицы, нижних уровней, содержащие полнотекстовый контент, но все же меняются. Если время на анализ таблиц будет сопоставимо с временем на проверку checksum, вероятно, так и сделаю.
Но вот все же, хотелось бы понять, почему checksum возбуждает такую критику у спецов? Ну проверка и проверка - в чем криминал, если не в потере времени, не в нарушении работы сайта?
В Moodle отслеживаются изменения в курсах и это используется при автоматическом резервном копировании - можно исключить курсы, не имеющие изменений с момента последнего копирования. Только этот механизм отслеживания не использует проверку CHECKSUM таблиц, вам это уже попытались объяснить, что это, мягко говоря, несколько глупо. Отслеживание основано на анализе таблицы логов, в которую записываются абсолютно все действия всех пользователей. Если найдены записи с какими-то изменениями в курсе, значит нужно создать свежую резервную копию этого курса. Вот и всё API
Вопрос косвенно связан с предыдущим.
Идея такая. Если нужна проверка изменений в конкретной записи можно использовать поле timemodified в тех таблицах, где оно присутствует. Но тут обнаружилась такая странная штука. В таблице lesson_answers поле timemodified присутствует, но какое-то неживое - при любых изменениях вопросов в странице там глухо сидит 0. Это - баг мудла или что-то в настройках?
(Moodle 2.8.12 PHP 5.4.45 MySQL 5.5.31 MS Windows 7)
конечно баг. для таких мелочей нет настройки. lesson несколько раз переписывался, может при каком-то переписывании забыли про эту колонку. Поставьте 3.9 и посмотрите, как там
Ясно.Спасибо.
Меня пока локальный сервер, так что переустановка - геморрой, проще сделать что-то типа md5.
