Удаление части сообщения по скрипту

[alaon]

Доброго дня! Недавно появилась такая идея - сделать на форуме бб-код для оффтопа, а также скрипт, который по крону осуществлял бы поиск среди сообщений этого тега и удалял бы его спустя какое-то фиксированное время. Как бы вы посоветовали организовать данный скрипт (прямая выборка из БД или есть какие-то спецсредства форума) и что я должен знать прежде, чем начну писать его?

[Sheer]

или есть какие-то спецсредства форума

Нет.

что я должен знать

php и MySQL

[владимир1983]

В мусор.

[alaon]

В мусор.

При всём уважении лично к вам, хотел обсудить эту тему глубже, выложить некоторые скромные наработки, но таки не буду, раз в мусор. Вообще, лёгкая у вас рука.

php и MySQL

Представление имею, а вот логику работы форума не знаю. Я предположил, что тупое удаление текста прямо из БД может оказать какое-либо негативное влияние на движок, потому и спросил. В конце концов, если тегом отмечено сообщение целиком, то оно улетит с БД, а индексы? Что нужно скорректировать перед удалением? Или лучше удалить функцией движка? Если да, как? Но обсуждение не состоится, поскольку см. выше. За сим прощаюсь.

[Sheer]

alaon, используйте родную функцию phpBB3

Код: Выделить всё

function submit_post($mode, $subject, $username, $topic_type, &$poll, &$data, $update_message = true, $update_search_index = true)

где первым параметром ($mode) выступает значение 'edit', а в качестве элемента массива $data['message'] отредактированный текст сообщения. Со структурой массива можно ознакомиться в файле posting.php - со строки 1091. Там же пример обращения к функции

Код: Выделить всё

			// The last parameter tells submit_post if search indexer has to be run
			$redirect_url = submit_post($mode, $post_data['post_subject'], $post_author_name, $post_data['topic_type'], $poll, $data, $update_message, ($update_message || $update_subject) ? true : false);

ЗЫ. С мусором погодим...

[rxu]

Я не представляю себе редактирование сообщений по крону, ибо это настолько ресурсозатратно, что не имеет смысла.
Крону придется каждый раз отбирать все посты, вырезать нужный кусок, и записывать их обратно. Если постов штук 100 - одно дело. А если 100 000 - вах, вах... без Deep Blue не обойтись.

[xisp]

Крону придется каждый раз отбирать все посты,

Простая колонка в БД с пометкой содержания в этом посте ббкода решит эту проблему чуть менее, чем полностью.

[Sheer]

удалял бы его спустя какое-то фиксированное время

Можно также заставить по крону просматривать сообщения только за этот период времени. Например, от текущего минус двое суток.

[rxu]

Простая колонка в БД с пометкой содержания в этом посте ббкода решит эту проблему чуть менее, чем полностью.

Эту проблему вернет обратно редактирование поста, чуть более, чем полностью.

[xisp]

Эту проблему вернет обратно редактирование поста,

При пересохранении само собой нужно будет перепроверять наличие ббкода и присваивать/ удалять метку о наличии этого ббкода.

[rxu]

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

Добавлено спустя 11 минут 31 секунду:
Хотя, если просто ограничить выборку определенным числом постов за 1 проход крона (например, 10), может быть и нормально.

[alaon]

Всем спасибо за ответы, вы дали много материала для размышления.

Простая колонка в БД с пометкой

Кстати, да, сам я не успел додуматься. Определённо, это разумный вариант, позволяющий распределить нагрузку во времени. Однако, я бы улучшил и этот вариант - делаем не колонку, а отдельную табличку, в которую вписываем идентификаторы сообщений, в которые помещён бб-код. Крон инициирует исполнение php-файла, который берёт информацию с этой колонки и делает выборку по данным id, после чего очищает таблицу. Насколько я припоминаю, это сильно ускорит процесс благодаря более разумной выборке в SELECT. Хотя могу ошибаться. Думаю, стоит сравнить оба варианта на предмет производительности. О результатах отпишу.

чуть более, чем полностью.

Лурк повсюду ) Будем проверять в функции отправки поста в БД.

приписать скрипт для синхронизации меток с содержимым постов

А я думаю, если определить для данных целей отдельную таблицу в БД, то ничего синхронизировать не придётся. Если только не повлиять на БД чем-то кардинальным, вроде STK или что там ещё есть... Но после такого рассинхронизация меток - самое безобидное, что может произойти, имхо.

[c61]

Зачем усложнять решение данной задачи, используя cron ? Намного проще через хук. И там уже разбираться, что делать и надо ли вообще что-то делать ) В ББ-код включается невидимый комментарий, время и дата есть в шапке поста, и тд и тп. Алгоритм прозрачен.

[rxu]

А еще проще - при открытии страницы темы с постами, всё одно парсится текст каждого. Хотя, тогда страница утяжелится запросами на запись в БД, но только при наличии нужных постов.

[xisp]

Насколько я припоминаю, это сильно ускорит процесс благодаря более разумной выборке в SELECT

Индексы уравняют эти варианты. Хотя нет. В случаи отдельной таблицы придётся опрашивать две таблицы, а не одну.

А еще проще - при открытии страницы темы с постами, всё одно парсится текст каждого. Хотя, тогда страница утяжелится запросами на запись в БД, но только при наличии нужных постов.

Тогда можно вообще не записывать изменения, а просто удалять текст. Пускай в БД лежит, но не отображается. Проблема может быть только если запустить форум без этой модификации- все "удалённые" участки всплывут.